automake
[Top][All Lists]
Advanced

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

Re: automake and gettext macros


From: Bruno Haible
Subject: Re: automake and gettext macros
Date: Tue, 30 Oct 2007 00:44:26 +0100
User-agent: KMail/1.5.4

[Stripping bug-gnulib from the CCs.]

Eric Blake wrote:
> > I could define
> > a macro AM_XGETTEXT_OPTION([option]) that would augment an AC_SUBSTed
> > variable which then gets used in po/Makefile, together with the
> > XGETTEXT_OPTIONS from po/Makevars. How does that sound?
> 
> Almost sounds okay, except as proposed, you would be injecting another
> macro into the Automake macro AM_* namespace.  Would you please consider
> renaming your macro to something like GT_XGETTEXT_OPTION

After 6 macros which start with AM_, the 7th macro provided by gettext should
start with GT_ ? This would not be very consistent either.

Or rename things like AM_GNU_GETTEXT after they are in use for 12 years?
No, that's not going to happen.

Instead of the separative thinking of automake vs. gettext vs. libtool vs.
gnulib, I would prefer to see more integrative thinking regarding the
GNU build system. Each of the 4 packages now has some tools for importing
*.m4 files ('aclocal', 'gettextize', 'libtoolize', 'gnulib-tool'), and
noone seems to think about how to reduce the problems caused by this
redundancy. The tools don't fit well together - they are obeying historically
grown interfaces.

> so that automake does not have to continually worry about names from its
> namespace being consumed by external packages

Except for one of the macros (AM_ICONV) which should better carry a gl_
prefix since it fits better into gnulib, all macros provided by gettext
have either GETTEXT or PO in their name. I assume automake will not
want to define macros with such syllables in their names? Just like
automake will not define macros that contain the syllable LIBTOOL. Then
there is nothing to worry about.

> and so that users trying to write bug reports against the macro have
> a better chance of guessing which package actually owns the macro?

To make this easier, I can add each of the 7 macros to gettext's info
dir category. So that "info AM_XGETTEXT_OPTION" directly opens up the
gettext manual. Would you find this good?

Bruno





reply via email to

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