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
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
