Bob Friesenhahn wrote: > On Fri, 1 Apr 2005, Gary V. Vaughan wrote: > >> Ralf Wildenhues wrote: >> >>> Hmm. "Always use our own libtool" sounds a lot like some bug needed >>> this. But then again, that line has been in there unchanged for six >>> years. I wonder if it will break setups if we change this, it's like >>> a rope to save us from stupid errors rather than a necessity. >>> >>> Anybody have good reasons against changing this? >> >> >> Running the tests in an older libtool.m4 and then using a newer installed >> libtool seems like a waste. If we want to do this, then we should >> probably >> skip all of the libtool tests at configure time and print a warning that >> LIBTOOL has been overridden in the environment. > > > Of course this may then cause the package to fail to compile since it > may have been depending on results of tests executed in libtool.m4.
Ah yes, good point. But that gives me a good idea for an enhancement to
HEAD... we could turn off all configure time tests, except those that are part
of the exported and documented API if, say, --enable-libtool-api-checks is
given at configure time. In conjunction with a prebuilt libtool, package
maintainers could check that they are not using undocumented features or
macros, and improve their chances of still working when they upgrade to a
newer libtool.
Actually, that interface sucks, but I like the principle. If we can come up
with a nice interface, let's put it in TODO!
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
