[PPL-devel] libtool generated by "GNU $PACKAGE"

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Wed, Mar 05, 2008 at 04:28:51AM CET:
> According to Ralf Wildenhues on 3/4/2008 2:14 PM:
> | Fixed with the patch below.  I don't care much that, in the Libtool
> | package itself, the will result in a libtool script with the line
> | # Generated automatically by config.status (libtool 1.2600 2008/03/02 02:19:16) 2.3a
> |
> | instead of GNU libtool.
>
> Hmm.  While this avoids the bug, I'm not sure if it was the best fix.

Granted, it's certainly debatable.  IMHO it's a strict improvement over
what we had before, though.

> |  # `$ECHO "$ofile" | sed 's%^.*/%%'` - Provide generalized library-building support services.
> | -# Generated automatically by $as_me (GNU $PACKAGE$TIMESTAMP) $VERSION
> | +# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION
>
> TIMESTAMP is a libtool invention, and is not documented in autoconf or
> automake as a typical variable.  At one point, M4 also tried using it, by
> parsing the CVS revision from ChangeLog, but ever since m4 switched to
> git, that aspect is broken (besides, I like what autoconf has achieved
> with intra-release versioning via the git-version-gen script).  Can we
> expect reasonable semantics from TIMESTAMP in all other libtoolized
> packages, if we don't document it?  Meanwhile, is there one of the
> Autoconf-provided variables, such as PACKAGE_NAME, which might fit better
> (and in the case of libtool, preserve the name 'GNU libtool')?

PACKAGE_NAME is currently not 'GNU libtool' for Libtool, also
PACKAGE_NAME is currently not available inside config.status (FWIW, I
feel that the fact that libtool even makes $PACKAGE available in
config.status is an ugly hack and a layering violation; OTOH you should
be able to decide at m4 time whether what we're bootstrapping is Libtool
or some third-party package).

Changing PACKAGE for the Libtool package requires somebody to audit all
code that matches comments in .lo and .la files and so on.  If TIMESTAMP
is empty because we are in a third party package, the above line has no
problem.  The exact timestamp and version of the Libtool used for
libtoolizing the third-party package is anyway found further down in the
libtool file, after the variable settings:

# Generated from ltmain.m4sh.

# ltmain.sh (GNU libtool 1.2600 2008/03/02 02:19:16) 2.3a

So frankly, the only thing that may be bothering at all is the missing
'GNU ' for the /usr/bin/libtool script which comes from the Libtool
package, and that TIMESTAMP may need adjusting when we move to git.
I let somebody motivated enough work on fixing the first, and will cross
the bridge for the second when I get to it.

Cheers,
Ralf