Re: Using libtool 2.0 in autoconf tests

[Sander Niemeijer]

On maandag, nov 22, 2004, at 15:29 Europe/Amsterdam, Gary V. Vaughan 
wrote:

> Hallo Ralf,
>
> Ralf Wildenhues wrote:
> > C'mon Gary, two questions: is it *possible* to provide the old 
> > behavior
> > without too much pain?
>
> I can't think of a way to do it cleanly :-(  But I have no objections 
> in
> principle.  How much machinery is there to make the config.status parts
> of AC_OUTPUT work?  Maybe we can create an _LT_OUTPUT macro to generate
> libtool at the end of LT_CONFIG?

The approach I have been thinking about would be like this. I could 
even imagine having an explicit (i.e. public) 'LT_OUTPUT' macro that 
generates the libtool script before AC_OUTPUT. In this case having a 
libtool script before AC_OUTPUT becomes an optional feature, that a 
configure script author might turn on by using the LT_OUTPUT macro 
before his own libtool-using tests.
I am definitely not opting for a removal of the libtool from 
AC_OUPUT/config.status. I can see the advantages of that. However, also 
(maybe optionally) being able to have libtool available before 
AC_OUTPUT would be extremely convenient.

There might even be a possible usage of being able to create a libtool 
script with LT_OUTPUT, perform a test, change some lt_ variable 
settings, create a new libtool script with LT_OUTPUT, perform a new 
test, etc.
Maybe useful for libtool tests?

> > Would that destroy some cool abstraction or some
> > really fundamental thing?
>
> It means that we no longer have to run configure twice, and cleans up 
> the
> the LT_INIT (nee AC_PROG_LIBTOOL) code path immensely.  I really don't
> want to go back to the old way of doing things... it was a mess.  
> However,
> there are certainly advantages to being able to call libtool from 
> within
> configure.
>
> > Or are you just waiting for a patch to do this?  (ok, that was three
> > questions now).
>
> I was hoping that we would be able to factor the common lt_* variable
> tests into new LT_* macros for people to use.

This would be one approach. However, the question is where you want to 
put the boundary of your libtool interface. You can make LT_ macros 
more independent by basing them on the libtool script (which has a very 
well defined interface). If you base LT_ macros on the more private 
lt_* variables than you tie the macros more to the inner workings of 
libtool and your dependency relations become a bit more complex. I 
think both approaches have their advantages and allowing both would 
therefore be the ideal solution IMHO.
People who want to write their own autoconf tests using libtool 
functionality would much rather try a solution based on an available 
libtool script (since this is the interface they know, unless maybe 
there are some good examples available on how to write an LT_ macro 
based on lt_* variables).
Other tests may only require a very small specific piece of knowledge 
that is provided by libtool, in such cases an lt_* variable based LT_ 
macro may be more convenient for test writers.

> > Sander, please don't start implementing such a thing *yet*.  I don't
> > think going this route is a good idea, but at least I think you should
> > wait until we are through with it.
>
> Seconded.

:-)

> Sander, if you want to check whether a particular library is shared,
> we should be able to write a macro for you to figure that out without
> actually needing to roll and run an entire libtool script.  Or is
> there more to your problem than that?

I just saw the reply from Kevin Fleming arrive in my mailbox and he 
perfectly describes the situations that should be covered.

My libtool 1.5.x macro that I posted before on the list is exactly the 
functionality that I want.

Best regards,
Sander