[Sorry for the previous mail; I accidentally sent a reply before I was
finished writing it]
On Thu, 02 Nov 2006 09:11:46 -0800, "Paul Eggert" <[EMAIL PROTECTED]>
said:
> Charles Wilson <[EMAIL PROTECTED]> writes:
>
> > Precedent: the fts and fts-lgpl modules each provide functionality
> > similar
On Thu, 02 Nov 2006 09:11:46 -0800, "Paul Eggert" <[EMAIL PROTECTED]>
said:
> Charles Wilson <[EMAIL PROTECTED]> writes:
>
> > Precedent: the fts and fts-lgpl modules each provide functionality
> > similar to the other, under different licenses -- where the module
> > under the lesser license pro
Bruno Haible <[EMAIL PROTECTED]> writes:
>> #define XNMALLOC(n, t) ((t *) xnmalloc (n, sizeof (t)))
>> #define XCALLOC(n, t) ((t *) xcalloc (n, sizeof (t)))
>
> Yes, this looks good. I'll use these names.
OK.
> #ifdef __cplusplus
> #define XALLOC_WITH_EXPRESSION(N,EXPR) xalloc_with_expression
Charles Wilson <[EMAIL PROTECTED]> writes:
> Precedent: the fts and fts-lgpl modules each provide functionality
> similar to the other, under different licenses -- where the module
> under the lesser license provides lesser, but still useful,
> functionality. That is the case here, as well: the ca
Sergey Poznyakoff wrote:
> The "gnulib" textual domain was defined exactly for that purpose.
OK, that is good for the moment as well. It is quite well translated already,
see http://www.iro.umontreal.ca/translation/registry.cgi?domain=gnulib .
What's missing is that gnulib-tool copies the POT & P
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Ad 2) We shouldn't ask the translators to translate the same strings
> repeatedly. Some translator groups have a shared translation memory, some
> don't. In the long term, I therefore think the right solution is that every
> gnulib module with translatable
Charles Wilson wrote:
> The variable name is $makefile_name, the command-line option is
> --makefile-name
Thanks, applied.
Bruno
Karl Berry asked on bug-gnulib:
> How do people maintain the list of Gnulib source files for POTFILES.in?
> Other than simply tracking the ever-changing list of sources, is there
> any built-in support of some kind?
>
> I can imagine writing a script that greps the gnulib dir or whatever,
> but ma
Paul Eggert wrote:
> If you look at the context of those lines in getgroups.c and
> group-member.c, you'll see that those lines are OK. (So I'm afraid
> the "sinner" is whoever's in charge of the rest. :-)
Yes. But in the group-member.c case, a macro that invokes xnmalloc would
simplify your cod
Roger Persson wrote:
> Great. But I wonder if there is one malfunction still in the script.
> What if the escape character isn't preceeded by a whitespace?
You're right. I wasn't aware that "make" replaces backslash-newline with
a space (unlike "sh", which replaces it with nothing). I'm applying t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[cc'ing bug-gnulib, since the bug really lies there, and bug-m4, since it
is a concrete example of an affected package. This started at
http://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg0.html.
Replies can probably trim all lists except b
[EMAIL PROTECTED] (Karl Berry) wrote:
> How do people maintain the list of Gnulib source files for POTFILES.in?
> Other than simply tracking the ever-changing list of sources, is there
> any built-in support of some kind?
>
> I can imagine writing a script that greps the gnulib dir or whatever,
> b
12 matches
Mail list logo
