[bug-gnulib] versioning macros (Was: Re: bnv_have_qt)

[Alexandre Duret-Lutz]

[Bastiaan complains that ac-archive macros use $Id$ instead of a
hand-written version.]

On Sat, Jan 15, 2005 at 10:46:00PM +0100, Bastiaan Veelo wrote:
> The inherent problem is that when John Doe has downloaded a macro whos
> version is defined with a CVS keyword, incorporated it into his project,
> committed it to his repository, that version number changes to something
> like "1.0, doe".

John should always use `cvs add -ko' when adding third-party files to
his tree.

But aside from that I generally try to avoid CVS keywords too.
Basically my feelings is that free softwares should not assume they
live in some given code managment system at some given place.
Assuming so simply sounds less free.  (For the same reason I have
always found awkward to generate a ChangeLog from CVS log messages,
since doing the converse requires just as much work while alowing the
ChangeLog to be cleaner and the package not to be tied to CVS.)

In Libtool, Automake, Gnulib, Gettext, many macros have a `#serial NNN'
line that is updated by hand.  Some tools use it when updating macros.

However #serial should soon cause problems with the way aclocal needs
to evolve.  The next version of aclocal should be able to install
macros into packages -- e.g, copy from /usr/share/aclocal to ./m4 --
or update macros therein.  For such update to work, some kind of
version comparison is required.  However due to some restriction on
the way we plan to implement the feature provided by aclocal in the
future, we cannot grep for this version information: it should be
--trace'able.  I have only briefly discussed this with Akim, and one
idea was to use something like

  m4_define([serial], [15])

and also allow

  m4_define([serial], [
  #serial 15
  ])

for backward compatibility with tools grepping for "^#serial \d+".
(Then we could introduce an Autoconf macro like AC_SERIAL([15]) that
would do the above more elegantly.  But we cannot support something
like AC_SERIAL directly, because some people will not want to use
a macro that cause their users to upgrade Autoconf.)

Of course none of this is definite, and it is not implemented either.
Perhabs people will have better ideas.