Hello Bruno, * Bruno Haible wrote on Mon, Mar 23, 2009 at 12:28:51AM CET: > > <http://lists.gnu.org/archive/html/bug-gnulib/2005-02/msg00000.html>
> > 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. There is a certain point to that. > 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. Yes. > - 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. Agreed. > - 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. Agreed. gnulib-tool and autopoint are already racing each other, which makes the `AUTOPOINT=true autoreconf -vi' necessary sometimes. Not adding another car into the race might just be a good thing. > 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. OK. > 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. OK. > 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. Great. We're all in violent agreement once all the information is on the table. :-) It is a bit sad to see that the aclocal scheme hasn't caught on more, but it's certainly not a perfect solution for macros which require being synchronized with other, non-macro files. Cheers, Ralf