Re: CVS & Gettext

[Bruno Haible]

Akim Demaille writes:

> | > cat >configure.ac <<EOF
> | > AC_INIT(Foo, 1.0)
> | > AM_INIT_AUTOMAKE([foreign])
> | > AM_GNU_GETTEXT
> | > AC_CONFIG_FILES(Makefile)
>     if $I_want_to_use_gettext; then
> | > AC_CONFIG_FILES(intl/Makefile po/Makefile.in)
>     fi
> | > AC_OUTPUT
> | > EOF
> 
> and have the proper thing happen.
> 
> In other words, you just cannot, and should not consider that the
> presence of an AC_CONFIG_FILES means the presence of a directory.

Right. It is for this reason that gettextize determines whether intl
is present by looking at the directory structure, not by looking at
the contents of configure.in/ac.

> And actually, IMHO, the best means to know that a directory exists is
> checking for its existence.  No?

Yup.

> The best means to see if configure.in is to be updated is looking at
> configure.in, no?

No. If gettextize has added an intl/ directory, it has to update
configure.in. Period. If gettextize has only updated a previously
existing intl/ directory, it doesn't have to update configure.in.

> It seems to me that your definition of consistent is not what users
> need.

Do users *need* to omit the intl/ directory?

> It turns out that, willing to do better than previous Gettext release,
> gettextize suddenly does worse.  The time where it did nothing to the
> source made it, surprisingly, less useful.

The newer gettextize does better for many people. It does worse for
you, because you omit essential source files from the CVS.

> There are many people out there who are somewhat lost with Autoconf,
> Automake, Libtool, Gettext etc.  They need simple interfaces, in
> particular when things go wrong.
> 
> That's the role played by autoreconf.

That's very clear. And it's not the purpose of gettextize, which is
merely a migration tool.

So let's work on a "gettextreconf" tool that you could invoke from
autoreconf.

Bruno