Hello Ralf,
> A compromise achieved after discussion on this (the bug-gnulib) list:
> <http://lists.gnu.org/archive/html/bug-gnulib/2005-02/msg00000.html>
Oh, I withdraw my criticism. Alexandre researched well, and asked on the
right list. Sadly, I was sleeping throughout the duration of this thread.
> Without consensus on the question whether interoperability is desirable,
> it is moot to discuss the format. As I read the archives, at some point
> in the past interoperability was deemed desirable by several members of
> this list
Yes, I see: "the whole area is crufty, and I think they can be removed."
said Paul Eggert.
Today, the situation is as follows, I would say:
- Interoperability between 'aclocal' and gnulib provided *.m4 files is
present, of course. What we are discussing is whether the 'aclocal'
feature to choose one or the other .m4 file based on the version number
should be applied to gnulib provided *.m4 files.
- In gnulib, the macro files, source code files, and Makefile.am snippets
form a unit. If gnulib provides an stdint.in.h that comes with stdint.m4
version 22, but 'aclocal' then chooses to prefer stdint.m4 version 23,
breakage in stdint.in.h is possible or even likely. It does not matter
from where this newer version of stdint.m4 came from. All that matters is
that gnulib-tool did not install it.
- Similarly, the gettext provided *.m4 files (gettext.m4, intl.m4, etc.)
form a unit. If one of them is replaced with a newer version and the
others are not, again, breakage is possible or likely.
For this reason, I don't think it's desirable that gnulib and gettext provided
macro files use the "# serial nn" syntax that activates the 'aclocal'
comparison feature.
Colin started this thread by pointing out a particular situation (multiple
copies of gettext.m4 in a source tree), and I hope I convinced him that this
situation is better avoided. A patch proposal for 'autopoint' to help avoiding
this situation is currently under consideration.
Alexandre wrote on 2005-02-01:
> 3. # FILENAME serial NNN
> 4. # FILENAME serial NNN (PACKAGES)
> 5. # FILENAME serial STRING (PACKAGES)
> ... the latter 3 schemes will be ignored by aclocal. At least in the current
> implementation.
This is fine as is, IMO.
Bruno
