bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib and gettextize


From: Bruno Haible
Subject: Re: gnulib and gettextize
Date: Fri, 25 Aug 2006 15:41:28 +0200
User-agent: KMail/1.9.1

Paul Eggert wrote:
> what is the
> recommended way to use AM_GNU_GETTEXT([external], ...), gnulib-tool,
> and autopoint/autoreconf ... autopoint brings in
> yet another (incompatible) copy of them.

Currently, there is a general problem: After a release is made, if users
do a "gnulib-tool --update", they will receive a newer gettext.m4 that
may be incompatible with the po/Makefile.in.in. I'm working with two
of the automake maintainers to transform po/Makefile.in.in into a
po/Makefile.am file; this will fix this problem.

A similar problem could also occur if the gettext.m4 macro in gnulib
deviates too much from what is in the latest gettext release. I'm trying
to limit this problem by moving to gnulib only "stable" changes.

> in such a way that you don't get the 
> following files into your m4 directory afterwards?
> 
>    glibc2.m4 intdiv0.m4 inttypes-h.m4 inttypes-pri.m4 lcmessage.m4
>    lock.m4 printf-posix.m4 size_max.m4 uintmax_t.m4 ulonglong.m4
>    visibility.m4 xsize.m4
> 
> These files are unnecessary in coreutils, because of the [external],
> and yet they're listed in modules/gettext

Yes. How could this be fixed? If we put the AM_GNU_GETTEXT([external],...)
invocation into the gnulib module description, how do people specify
the arguments passed to AM_GNU_GETTEXT?

> It also comments out this line:
> 
> AM_CPPFLAGS += -I$(top_builddir)/intl
> 
> to simplify the output of "make".

Such a minor modification of a module description can be accommodated
through a .diff file and the --local-dir option.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]