All,

The `versioning of libraries' item made it to the top of the list.

I got something pretty much working in the sense that it works as m4
macros in isolation, but which (as I discovered at the end of the day,
when I tried to integrate it into the rest of the starconf system)
apparently can't make it unmangled through the autoreconf process.  I
probably can get it to work with a bit of extra indirection, but it's
suddenly starting to look rather fragile.

It was also going to be rather complicated to use, to the extent that
I'm wondering whether it would be better for package maintainers to do
this by hand.  The documentation for the macro would probably not be
much different in size or complication from the documentation for using
the -version-info option by hand (or rather, in the Makefile.am).

The issue is that the library -version-info is _not_ the package
version number, but a statement of the _interface_ version, in the form
of a triple current:revision:age.  'Current' is the interface version,
as a monotonically increasing integer, and 'age' is a statement of how
many interfaces are compatible with it: if a library has a triple
c:r:a, then it implements all the interfaces between versions c-a and
c, inclusive.  When you're making a new release of a library which had
the -version-info c:r:a,

   * If the interface is unchanged, but the implementation has changed
or been fixed, then increment 'r'.
   * Otherwise, increment 'c' and zero 'r'.
     * If the interface has grown (that is, the new library is
compatible with old code), increment 'a'.
     * If the interface has changed in an incompatible way (that is,
functions have changed or been removed), then zero 'a'.

That is, this version-info triple is not straightforwardly related to
the package version number, any more than RCS revision numbers are.  I
had a cunning macro which managed to implement the above rules, but
depended on the user indicating with a string which of the above cases
was relevant, and the documentation for which would not actually be
shorter or more limpid than the account above.

The libtool docs (at
<http://www.gnu.org/software/libtool/manual.html#SEC35>, of which the
above is a precis) explicitly warn against trying to synchronise this
number with the package version number, and I can see the force of that
proscription.

There is also a -release option, which does take a package version
number as argument.  The docs mention this as a reasonable way of
indicating which package release version this library was built from,
but only by rather missing one of the points of shared libraries, since
it means that no shared library is compatible with any other.

I suggest, therefore, that we do not try to automate this.  If we want
to use shared library versioning (and I think this would be a Good
Thing), then we do it by hand, by adding "-version-info c:r:a" in the
Makefile.am libxxx_la_LDFLAGS, and documenting how to increment c:r:a.
If we don't want to bother with versioning, but want the source-code
release in the library name, for documentation purposes, then we add
"-release @PACKAGE_VERSION@"  to the libxxx_la_LDFLAGS.  I've verified
that this latter does appear to work, in the sense that I get a
.libs/libcnf-4.0-2.dylib in a suitably tweaked CNF Makefile.am
(choosing this library rather at random).

So, do we want library versioning?

Norman


--
----------------------------------------------------------------------
Norman Gray  :  Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk