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