Re: Automatic regeneration of libtool

[Gary V. Vaughan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Alexandre,

Alexandre Duret-Lutz wrote:
|>>>"Gary" == Gary V Vaughan <address@hidden> writes:
|  Gary> Instead, I'd like to have LT_INIT perform the
|  Gary> AC_SUBST([LIBTOOL_DEPS]), and Automake generate the
|  Gary> following rule when libtool is in use:
|
|  Gary> $(LIBTOOL): $(top_builddir)/config.status $(LIBTOOL_DEPS)
|  Gary>         cd $(top_builddir) && $(SHELL) ./config.status $@
|
|  Gary> Does that seem like a sensible thing to want?
|
| What does LIBTOOL_DEPS contains?

For current libtool, LIBTOOL_DEPS always points at the ltmain.sh that was used
to generate the libtool script.  In the future, we might remove ltmain.sh in
favour of an m4sh based libtool generation, in which case it would become
empty.  More on this in a moment...

| It's unclear to me when
| libtool needs to be rebuilt and how me managed without such rule
| so far.

I think libtool needs to be rebuilt whenever a project is re-libtoolized,
which can be detected by having a newer ltmain.sh.  This works best with links
I expect, but if someone (say 'autoreconf -f' ;-) 'libtoolize --copy --force's
their tree, it is not unreasonable for libtool itself to be rebuilt (and
thence libtool objects recompiled).

|  Except in the Libtool package itself, I believe
| libtool.m4 does change when ltmain.sh changes, doesn't it?

Theoretically we could make a point release that changes the contents of one
but not the other (relative to the previous release): and libtoolize no longer
blindly overwrites either file if there are no changes in serial number
(excepting --force of course).

LIBTOOL_DEPS should probably include a list of the srcdir macro files too to
catch this case.

| So libtool would get updated as a side-effect of
| rebuilding/rerunning configure.

Yes, that is true.  But does configure get rebuilt automatically if a tree is
relibtoolized?  I don't think the current automake rules notice that ltmain.sh
has been touched.

| I have a small problem with using $(LIBTOOL) as a target of a rule,
| because many people have overwritten LIBTOOL in they Makefile.am
| to insert a --tag option.

Good point.  Perhaps Automake could /s, -[-a-zA-Z0-9]*,,g/ on $(LIBTOOL) and
put the result of that in place of the $(LIBTOOL) target in Makefile.in?  Or
maybe we need a LIBTOOL_FLAGS to hold the options?

| Also such a rule would be triggered only if something depends on
| $(LIBTOOL), which I believe is not the case (same problem with
| --tag here).  Is such a dependency desirable?  IOW should every
| libtool target be recompiled whenever config.status changes?

Well, if libtool has been regenerated, and is different, then certainly
libtool targets should be recompiled.  If config.status has changed, then
there is a real possibility that libtool will be different, and having libtool
objects from different builds of the libtool script scattered around the tree
is definitely to be avoided! :-/  I don't think we can get any finer
granularity than this; and it is better to be conservative than force a
frustrated user to 'make distclean' and start again when things go awry.

FYI, there has been some version of the $(LIBTOOL) target rule in all of the
Makefile.ams in the libtool dist for as long as I can remember (about 5 or 6
years on a lucid day ;-) ...

Cheers,
        Gary.
- --
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://www.oranda.demon.co.uk
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFARGmSFRMICSmD1gYRAshWAJ9WADAUjQXEZQRu65CL1YDG3zt+1wCgzhWO
jRLKoQ0l7DEIR5hzmeyw6Xg=
=k+pp
-----END PGP SIGNATURE-----