Re: Serial number formats

[Ralf Wildenhues]

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