Re: serial in branch-1-5 [[and branch-2-0]]

[Alexandre Duret-Lutz]

>>> "Gary" == Gary V Vaughan <address@hidden> writes:

[...]

 Gary> IIRC Libtoolize greps aclocal.m4 for '#serial [0-9]+
 Gary> LTDL_INIT' et. al.  and compares matching serial numbers
 Gary> against installed ltdl.m4 and libtool.m4 to diagnose
 Gary> ltmain.sh vs. macro version mismatches and (not yet
 Gary> implemented) only upgrade in-tree libtool.m4 and ltdl.m4
 Gary> with libtoolize --install when the result will not cause
 Gary> a mismatch.

Thanks for explaining, I was about to ask the purpose of this
macro name.

But isn't libtoolize intended to be run before aclocal ?  If so
why does it grep aclocal.m4 ?  It would find the definition of
the old macro.

 Gary> One of the outstanding bugs in branch-2-0 that is
 Gary> preventing a full release from that branch is the problem
 Gary> with serial numbers.  I'm hoping that we might be able to
 Gary> defer to aclocal for macro serial number management to
 Gary> reduce the branch-2-0 release blockers...

I sincerely hope you won't wait for Automake 1.10 to release
Libtool 2.0, because Automake 1.10 itself has to wait for
Autoconf 2.60.  We had [*] such a dependency chain more than one
year ago when Libtool 1.6 was waiting for Automake 1.8 which was
waiting for Autoconf 2.58, and it didn't help Libtool to be
released (my impression is that instead the wait caused more
serious changes to be introduced).

[*] http://lists.gnu.org/archive/html/autotools-announce/2003-10/msg00000.html


 >>> Anyway the explanation of the format in the documentation is the
 >>> same that is output when aclocal warns it does not understand a
 >>> serial number.  It looks pretty explicit to me:
 >>> 
 >>> /home/adl/usr/share/aclocal/libtool.m4:30: malformed serial number `49 
 >>> LT_INIT', expecting only digits and dots

 Gary> My guess is that aclocal already updates in-tree m4 macro files with
 Gary> respect to serial numbers in the format it understands, 

The current manual presents it as follows.

| 5.4 aclocal options
| ===================
| 
[...]
| 
| `--install'
|      Install system-wide third-party macros into the first directory
|      specified with `-I DIR' instead of copying them in the output
|      file.
| 
|      When this option is used, `aclocal' will also honor `#serial
|      NUMBER' lines that appear in macros: an M4 file is ignored if
|      there exists another M4 file with the same basename and a greater
|      serial number in the search path.
| 
[...]
| 
| 5.8 Handling Local Macros
| =========================
| 
[...]
| 
|    However there is no consensus on the distribution of third-party
| macros that your package may use.  Many libraries install their own
| macro in the system-wide `aclocal' directory (*note Extending
| aclocal::).  For instance Guile ships with a file called `guile.m4'
| that contains the macro `GUILE_FLAGS' which can be used to define setup
| compiler and linker flags appropriate for using Guile.  Using
| `GUILE_FLAGS' in `configure.ac' will cause `aclocal' to copy `guile.m4'
| into `aclocal.m4', but as `guile.m4' is not part of the project, it
| will not be distributed.  Technically, that means a user which needs to
| rebuild `aclocal.m4' will have to install Guile first.  This is
| probably OK, if Guile already is a requirement to build the package.
| However, if Guile is only an optional feature, or if your package might
| run on architectures where Guile cannot be installed, this requirement
| will hinder development.  An easy solution is to copy such third-party
| macros in your local `m4/' directory so they get distributed.
| 
|    Since Automake 1.10, `aclocal' offers an option to copy these
| system-wide third-party macros in your local macro directory, solving
| the above problem.  Simply use:
| 
|       ACLOCAL_AMFLAGS = -I m4 --install
| 
| With this setup, system-wide macros will be copied to `m4/' the first
| time you run `autoreconf'.  Then the locally installed macros will have
| precedence over the system-wide installed macros each time `aclocal' is
| run again.
| 
|    One reason why you should keep `--install' in the flags even after
| the first run is that when you later edit `configure.ac' and depend on
| a new macro, this macro will be installed in your `m4/' automatically.
| Another one is that serial numbers can be used to update the macros in
| your source tree automatically when new system-wide versions are
| installed.  A serial number should be a single line of the form
| 
|      #serial NNN
| 
| where NNN contains only digits and dots.  It should appear in the M4
| file before any macro definition.  It is a good practice to maintain a
| serial number for each macro you distribute, even if you do not use the
| `--install' option of `aclocal': this allows other people to use it.
| 
[...]

 Gary> but how can it compare serial numbers in aclocal.m4 when
 Gary> out-of-tree macros are used if there is no indication of
 Gary> source file against the many #serial lines in aclocal.m4?

It does not.  aclocal writes aclocal.m4 but does not read it and
never did, this is why we prefer to distribute m4 files
separately.

The serial numbers are just used to help people not to update
their m4/* files by hand (and hopefully simplify future fooize
scripts).  If you don't use --install, aclocal will not honor
#serial numbers (but will still diagnose those it doesn't
understand to sanitize the field).

 Gary> I think that it should be possible to drop libtoolize entirely from
 Gary> future releases of Libtool (though we still need a way to copy libltdl
 Gary> into a project tree) if we make sure aclocal can manage libtool's
 Gary> macro serial numbers properly.  Hopefully, little more than using
 Gary> conformant serial numbers is necessary???

aclocal itself does not need more than a number to work.  I
foresee the current regex will have to be relaxed in some way
(e.g., I've seen that gnulib uses many different serial
syntaxes), but it's not yet clear to me how.

A different idea is to drop the idea of #serial, since it has
already been employed in several incompatible ways, and use a
fresh syntax.  E.g. #version.
-- 
Alexandre Duret-Lutz