Re: CVS & Gettext

[Akim Demaille]

| Akim Demaille writes:
| > Bruno> In the tests I made, running gettextize a second time didn't
| > Bruno> change anything. Can you provide a testcase?
| > 
| > Sure!
| > 
| > mkdir foo
| > cd foo
| > cat >configure.ac <<EOF
| > AC_INIT(Foo, 1.0)
| > AM_INIT_AUTOMAKE([foreign])
| > AM_GNU_GETTEXT
| > AC_CONFIG_FILES(Makefile)
| > AC_CONFIG_FILES(intl/Makefile po/Makefile.in)
| > AC_OUTPUT
| > EOF
| > cat >Makefile.am <<EOF
| > SUBDIRS = po intl
| > EOF
| > autoreconf -f -v -i
| 
| This is an inconsistent testcase: You declare that there is an 'intl'
| subdir but it is not there.

I don't declare anything like this.  I declare that there will
probably be a directory there, with a Makefile to instantiate.  Given
the semantics of Autoconf, I am perfectly allowed to write

| > 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.

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

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


| In this case gettextize sees that there is no 'intl' directory and
| proceeds to add support for it in configure.in and Makefile.am -
| assuming a consistent starting situation.

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



| > Also, another related problem is that if I use AC_CONFIG_AUXDIR, then
| > config.rpath will be put there.  Fine!  But it is EXTRA_DISTed in the
| > top level Makefile.am, even if it is already EXTRA_DISTed in the
| > auxdir's Makefile.am.
| 
| Same thing here: If the config.rpath already exists as a file in
| auxdir, then gettextize will not add it to the top level Makefile.am.
| So again what you observe is a consequence of an inconsistent source
| package.

I think you made your point extremely clear, nevertheless, please
consider the point of view of the usefulness.  Gettextize, by merely
checking the files that it intends to change, instead of looking at
something else, becomes much more predictable and more usable.  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.


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.  When a mismatch happens, when
something goes wrong and configure and/or Makefile.in and/or
config.hin and/or aclocal.m4 are broken and/or some library files such
as gettext's, asking for them to track down the origin of the failure
and precede step by step till they can finally run ./configure is too
steep.

What is needed is something simple.

gettextize already assists its users in a certain way.  If only it
looked at the files it modifies before modifying them, things would be
much simpler for everybody.

Please, reconsider your position, and make gettextize more useful.