Re: gnulib and gettextize

2006-09-09 Thread Bruno Haible
Eric Blake wrote: > It is not possible to know what macros will be invoked later in the file. > But with diversions, it is possible for macros invoked later to emit > shell code that will be invoked earlier, by making sure that > gt__NEED_NGETTEXT_FU expands to shell code in a lower diversion numb

Re: ensure that generated files are read-only

2006-09-09 Thread Bruno Haible
Jim Meyering wrote: > > 2) For the user who needs to fix a compilation problem, or do minor > >developments in a package. > > > >In this case I _do_ want to change the Makefile or config.h, to see > >the results. Because if I change Makefile.am or *.m4, I will have to > >wait 5 minu

Re: ensure that generated files are read-only

2006-09-09 Thread Bruno Haible
Jim Meyering wrote: > >> Bruno, would you mind if I changed the uses of "t-$@" to "[EMAIL > >> PROTECTED]" > >> in modules/localcharset? > > > > Yes. The rule would not work right any more on 8+3 filesystems (DJGPP, > > possibly also OS/2). > > Do you know of actual users who have to _build_ GNU

Re: *_LDFLAGS vs. *_LDADD vs. *_LIBADD

2006-09-09 Thread Bruno Haible
Ralf Wildenhues wrote: > Actually, you should not put `-l*' into LDFLAGS at all, > those belong into LIBS, *LDADD, or lib*_LIBADD (the latter being useful > for libtool libraries only). This is not how automake documents these variables. The doc (node "Libtool Flags") says that I can augment only

Re: gnulib-tool: support for LDFLAGS, LIBDEPS and LTLIBDEPS

2006-09-09 Thread Bruno Haible
Ralf Wildenhues wrote: > *_LDFLAGS are for libtool libraries and programs, but not for static > libraries. Ah, right, I forgot about this. Sorry. > I recommend that if libgnu.a needs symbols from other libraries, then it > should provide a macro $(LIBGNULIB) or so, that programs can use to link >

Re: gnulib and gettextize

2006-09-09 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 9/9/2006 11:26 AM: > Gary V. Vaughan wrote: >> Untested: >> >> m4_define([gt__NEED_NGETTEXT_FU], >> [shell code to execute after expansion of AM_GNU_GETTEXT, >> whenever AM_GETTEXT_NEED_NGETTEXT is present somewhere]) >>

Re: program_name in error.c

2006-09-09 Thread Sergey Poznyakoff
Eric Blake <[EMAIL PROTECTED]> wrote: > Careful. error.c is (mostly) synced upstream with glibc (right now, all > but the comments and a couple of #include order issues), but this would > widen the gap. Yes, I see that the matter is not as simple as it seemed at the first glance. > As it is, er

Re: gnulib and gettextize

2006-09-09 Thread Bruno Haible
Gary V. Vaughan wrote: > Untested: > > m4_define([gt__NEED_NGETTEXT_FU], > [shell code to execute after expansion of AM_GNU_GETTEXT, > whenever AM_GETTEXT_NEED_NGETTEXT is present somewhere]) > > AC_DEFUN([AM_GNU_GETTEXT], > [ > ...current contents of AM_GNU_GETTEXT definition... > > dnl make

Re: [bug-gnulib] Fixing argp doc strings

2006-09-09 Thread Sergey Poznyakoff
Bruno Haible <[EMAIL PROTECTED]> wrote: > Sure. But N_(...) does apply to it. One might document this, otherwise > the programmer might think that he needs to fill in the translation himself > into the ->doc field at runtime, not knowing that the argp implementation > does it for him. Ah, yes, in

Re: [bug-gnulib] Fixing argp doc strings

2006-09-09 Thread Bruno Haible
Sergey Poznyakoff wrote: > The 'doc' field of argp_option has a different > semantics, '\v' does not apply to it. Sure. But N_(...) does apply to it. One might document this, otherwise the programmer might think that he needs to fill in the translation himself into the ->doc field at runtime, not

Re: [bug-gnulib] program_name in error.c

2006-09-09 Thread Bruno Haible
Sergey Poznyakoff wrote: > If it is called before argp_parse it will > surely coredump. But then, we cannot guarantee that whoever is using > this interface will set program_name before calling error(), can we? We need to document it somewhere, in error.h or argp.h. Bruno

Re: [bug-gnulib] Fixing argp doc strings

2006-09-09 Thread Sergey Poznyakoff
Bruno Haible <[EMAIL PROTECTED]> wrote: > Additionally, how about documenting this > (non-obvious) convention? Something like this: Thank you. I have applied this change. > Also, one could mention the need of N_(...) in the documentation of > the field 'doc' of struct argp_option as well: No,

Re: [bug-gnulib] program_name in error.c

2006-09-09 Thread Sergey Poznyakoff
Bruno Haible <[EMAIL PROTECTED]> wrote: > - Why do you use HAVE_PROGRAM_INVOCATION_NAME here, whereas argp.m4 > defines GNULIB_PROGRAM_INVOCATION_NAME ? Yes, I meant GNULIB_PROGRAM_INVOCATION_NAME, of course. > - If the #ifdef condition is true, you'll be using the > program_invocation_name

Re: program_name in error.c

2006-09-09 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sergey Poznyakoff on 9/8/2006 11:42 PM: > Hello, > > I'd like to install the following change to error.c in order to > better cooperate with argp. Any objections? Careful. error.c is (mostly) synced upstream with glibc (right now, all

Re: [bug-gnulib] program_name in error.c

2006-09-09 Thread Bruno Haible
Sergey Poznyakoff wrote: > --- error.c 29 Aug 2006 16:58:34 - 1.46 > +++ error.c 9 Sep 2006 05:39:50 - > @@ -92,9 +92,13 @@ extern void __error_at_line (int status, > char *strerror_r (); > # endif > > +#ifdef HAVE_PROGRAM_INVOCATION_NAME > +# define program_name program_invoca

Re: [bug-gnulib] Fixing argp doc strings

2006-09-09 Thread Bruno Haible
Sergey Poznyakoff wrote: > 2006-09-09 Sergey Poznyakoff <[EMAIL PROTECTED]> > > * argp-help.c (argp_doc): Split the untranslated doc string on > '\v', and translate the two parts separately, instead of > feeding the whole string to gettext. This allows to exclude >