Re: Using libtool 2.0 in autoconf tests

[Gary V. Vaughan]

Hi Sander,

Sander Niemeijer wrote:
> I hope it is clear that I only want to perform a test that checks
> whether a certain library is available and whether it is possible to
> link this library against another shared library (which means it should
> be a shared library itself). Now, of course, in theory I could write
> such a test without performing an actual link or without making use of
> libtool. This, however, would mean I would have to add a _lot_ of
> knowledge to my test in order to have it work on many platforms with
> many compilers/linkers. Knowledge which is usually already available in
> the linker (i.e. just trying to link will usually tell you whether it
> works or not) and/or the libtool script. Not even considering the
> practical points here, even from a theoretical standpoint duplicating
> knowledge is _not_ a good idea.

Agreed.  I think that there are a small number of circumstances where
the early-build of libtool was genuinely useful, and I think we should
be able to wrap each of those cases is a shipped macro that leverages
the knowledge already probed for libtool without needing to actually
have a libtool script present.

Most of the time people were just grepping the libtool script for the
value of some variable.  But your's is one of the few cases that needs
a whole new macro.  I'd be delighted if you want to help us write it,
but it should then be part of libtool.m4, not your package!

> Now suppose I would use the knowledge provided by libtool are you then
> suggesting that libtool should have _two_ interfaces that I should use?
> One for use from makefiles (i.e. the libtool script) and one to use from
> the configure script (some undocumented combination of lt_ variables and
> ltmain.sh)? If this is it, then so be it and I will try to rewrite my
> autoconf test to use the lt_/ltmain.sh combination for libtool 2.0,
> but libtool 2.0 surely won't get my vote for the
> best-design-of-the-year-award.

No no, I think that the post-1.5 interface is incomplete.  And with good
reports like yours, we should be able to fill in the gaps.

It may turn out that we have to figure out a new way to generate libtool
without config.status in the end, but considering the mess it got us into
before, I'd like to try to solve configure time problems by enhancing
the configure interface.

> I can perfectly understand why you want to take this approach for
> libtool tests and I think it is a good idea. But IMHO the libtool
> configure script variables and the ltmain.sh script should not be part
> of the interface that is presented to the end-user of libtool. Users
> should only have to be confronted with the libtool script. Just give us
> _one_ consistent interface please.

No, they should not, and are not.  Nor should grepping the libtool script,
or .la files be part of the user interface to Libtool.  We just need to
figure out which parts of the LT_ macro interface need opening up and
documenting.

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