[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool.m4 option to use installed libtool

From: Gary V. Vaughan
Subject: Re: libtool.m4 option to use installed libtool
Date: Fri, 01 Apr 2005 16:17:14 +0100
User-agent: Mozilla Thunderbird 0.9 (X11/20041103)

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!

Gary V. Vaughan      ())_.  address@hidden,}
Research Scientist   ( '/
GNU Hacker           / )=
Technical Author   `(_~)_

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]