libtool
[Top][All Lists]
Advanced

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

Re: Using libtool 2.0 in autoconf tests


From: Sander Niemeijer
Subject: Re: Using libtool 2.0 in autoconf tests
Date: Mon, 22 Nov 2004 11:00:13 +0100

The theory:

It is my belief that an actual link should not be necessary to test
for some characteristic.  Libtool runs a whole lot of autoconf tests
at configure time to decide how it is going to link when the results
of those tests are added to the generated libtool script. Consequently,
you should be able to work out how the generated libtool script will
behave under any circumstance by examining the results of the configure
time tests that LT_INIT (and maybe LT_WITH_LTDL) have made available to
you at link time.

There are still a small number of host dependent decision that are made
by the code in ltmain.sh, and it is possible that you need to know what
decision will be made in that case.  In order for this to work, we need
to parameterize any such decisions at configure time, and change ltmain.sh to use the new parameter rather that a hardcoded $host_os
decision.  We need to consider any occurences of these that turn up to
be priority bugs.

The practice:

If you think about what it is you need to know in these terms, you
should be able to figure out what libtool will do by looking at the
results of the LT_INIT configure time tests.  If you can't, then try
to express your problem in those terms on this list, and we will be
able to figure it out for you -- and maybe make a new macro that rolls
that condition case up to help make it easier to figure out next time;
and maybe notice that there is something in ltmain.sh that needs to be
parameterised to make it possible.  It might be worth adding some notes
about this to libtool.texi, where we can later collect additional notes
that walk through some examples to help future users get into the right
mindset.

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.

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.

An aside:

As we rewrite the testsuite on HEAD, I want to change as many of the
tests as possible to use this paradigm instead of  configuring an
entire mini-project to test that some aspect of linking is working.
We need some of these slow tests too; but the current testsuite is
very slow because of the number of unneccessary project bootstraps
it has to run.  Fixing this will also affect the libtool distcheck
time dramatically in more than the obvious sense, because we won't
need to bootstrap all of these directories with aclocal, autoconf
and automake.

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.

Best regards,
Sander





reply via email to

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