Re: AM_GNU_GETTEXT weirdness

[Bruno Haible]

Marius Vollmer wrote:
> >> running ./autogen.sh now runs gettextize

autoreconf shouldn't run gettextize. This was fixed in autoconf-2.57.

> >> and that causes some
> >> 'useless' things to happen, like the creation of po/

If you don't want a po/ directory, just don't run gettextize, and instead
do the steps (explained in the GNU gettext manual, chapter
"The Maintainer's View") manually.

> >> and the inclusion
> >> of po/Makefile.in in _all_ AC_CONFIG_FILES statements in configure.in.

This is a bug in gettextize that is fixed in the current gettext CVS
(not yet released; sorry).

> >>   Makefile.am:26: AM_GNU_GETTEXT used but `po' not in SUBDIRS

This is fixed in automake 1.8 and newer.

Jan Nieuwenhuizen wrote:

> > I have no clues whatsoever about what the developers of auto* have in
> > mind.  You'll have to ask Bruno about the AM_GNU_GETTEXT/libintl stuff.
> > What I had initially, was
> >
> >     dnl i18n tests
> >     AC_CHECK_HEADERS([libintl.h])
> >     AC_CHECK_FUNCS(gettext)
> >     if test $ac_cv_func_gettext = no; then
> >        AC_CHECK_LIB(intl, gettext)
> >     fi
> >     AC_CHECK_FUNCS([bindtextdomain textdomain])
> >
> > maybe something like that is better?
>
> Bruno, what is your view?

That autoconf test fails to detect an existing GNU libintl on _all_ platforms.
(Moreover it would pretend to have found gettext on Solaris without
GNU libintl, which would lead to linker errors later.)
Thus it works only on glibc systems, where no libintl is needed.

That's why I recommend the AM_GNU_GETTEXT macro.

> I have a hard time convincing myself now that gettext support should
> be in the core, when I have, for example, not accepted SCTP.  Hmm.

You have to estimate the importance of internationalization.

For illustration: In a new Linux magazine special issue about PHP 5, there
were about 6 or 7 introductory articles about this language and environment.
One of them was about how to use gettext from within PHP.

Bruno