-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Salut Alexandre,
Alexandre Duret-Lutz wrote: |>>>"Gary" == Gary V Vaughan <[EMAIL PROTECTED]> 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 ())_. [EMAIL PROTECTED],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.orgiD8DBQFARGmSFRMICSmD1gYRAshWAJ9WADAUjQXEZQRu65CL1YDG3zt+1wCgzhWO jRLKoQ0l7DEIR5hzmeyw6Xg= =k+pp -----END PGP SIGNATURE-----
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
