Re: libtool.m4 option to use installed libtool

[Gary V. Vaughan]

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      ())_.  address@hidden,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