* Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET:
I have some self written autoconf tests that check for linking shared libraries against some specific other libraries (these other libraries should be available as shared libraries or we might have a PIC problem. That is what my tests checks for). For this I had to create a variant
*snip*
I agree with your view of things. I think we should allow this to be done.
Gary, you did the whole bootstrap reorganization. Is anything close to this possible?
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.
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.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],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
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
