On Mon, Mar 16, 2009 at 01:13:52PM +0100, Bruno Haible wrote:
> Hello Colin,
>
> > I'm using both gettext and gnulib. In order to avoid confusing file
> > conflicts, I tell gettext to install into m4/ and gnulib to install into
> > gnulib/m4/, and rely on aclocal's documented serial number handling to
> > sort it out. I use '-I m4 -I gnulib/m4' in ACLOCAL_AMFLAGS since
> > autopoint installs into the first -I directory in ACLOCAL_AMFLAGS.
>
> The recommended way to solve this conflict is documented in the gnulib manual:
>
> <http://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html>
This is inadequate because it requires you to run gnulib-tool between
autopoint and aclocal, and then you cannot use autoreconf and have to
reinvent the wheel.
We've exchanged mails about this before ("gnulib-tool and autoreconf" on
bug-gnulib). You said (on bug-autoconf):
> It would seem odd to have 'autoreconf' invoke 'gnulib-tool'. gnulib-tool
> is a tool that *fetches* source files, whereas autoreconf is a tool that
> *combines* source files, generating additional files from them.
> Therefore gnulib-tool logically belongs before autoreconf.
>
> Also I'd like to avoid to have mutual dependencies between autoconf/automake
> and gnulib.
>
> Therefore I would find it better if autopoint had an option that tells it
> not to overwrite .m4 files installed by gnulib-tool, or if that behaviour
> was even the default. What do you think?
This involves calling gnulib-tool before autopoint, not after it as the
gnulib manual recommends. At the time I thought your proposal would be
enough to resolve my problem and unfortunately didn't look into it
further. Now I realise that it only works if you let gettext and
gnulib-tool install their macros into the same directory.
(I'm still using gettext 0.17 so haven't yet had an opportunity to try
out your autopoint patch in that thread, but I think the above statement
is true.)
> I'm feeling that letting the user put different versions of gettext.m4,
> lock.m4, etc. into his working tree and then relying on 'aclocal' to sort
> it out is too risky. For example, the user may omit a -I option in some
> particular subdirectory; then 'aclocal' may choose the older version without
> complaining. It is better if the user has only one version of gettext.m4
> in his working tree.
At the moment it only complains if you're unlucky anyway.
I would find it more elegant to install all the files separately and
have a defined ordering between them, the way that the aclocal
documentation says will happen. I don't want to tell autopoint to
install its files into gnulib/m4/ (that just seems odd and somewhat
likely to result in stray macro files lying around that I don't need),
and I definitely don't want to tell gnulib to install its files into m4/
because I keep my own macro files there and I would prefer that they
stayed separate from the very extensive collection provided by gnulib.
TBH I don't find the "missing -I" argument very persuasive as this is
the sort of thing that can already happen in various situations (for
example, gettext.m4 might be in /usr/share/aclocal/ and not in your
working tree at all) and it doesn't seem to be a major problem.
In any case, I don't see why this is an argument for using a serial
number format that's incorrect per the documentation. Why bother with
serial lines at all in that case? They just mislead people into thinking
that everything will work the way aclocal normally does until they look
into it in detail. Correct serial lines would not inconvenience people
using the procedure recommended in the gnulib manual, and would make
things better for those of us who are trying to make gnulib-tool and
autoreconf actually play nicely together. :-)
The only argument I can see for not providing working serial lines is to
save on maintainer confusion by making it break if you get it "wrong"
(but only break sometimes, depending on which macros you use and the
relative dates of the versions of gettext and gnulib you're using). But
I am confused anyway ...
Hmm. Maybe an alternative answer would be to extend your earlier
autopoint patch so that it looks for .m4 files in *all* directories in
ACLOCAL_AMFLAGS for the purposes of serial number comparison, rather
than just .m4 files in the directory gettext is installing into? That
would duplicate aclocal's work a bit, but would solve the same kind of
problem as you were trying to address in
http://www.mail-archive.com/bug-autoc...@gnu.org/msg01896.html.
Beyond the gettext compatibility issue, there are many files in gnulib
that have serial lines in a format not recognised by aclocal that have
nothing to do with gettext. Is there a good reason for these? I'd list
them here but there seem to be over 300 of them.
Thanks,
--
Colin Watson [cjwat...@debian.org]
