Re: conditionally using libtool

[Bob Rossi]

On Sat, Apr 29, 2006 at 05:50:41PM +0200, Ralf Wildenhues wrote:
> * Bob Rossi wrote on Sat, Apr 29, 2006 at 12:15:49PM CEST:
> > On Sat, Apr 29, 2006 at 09:09:19AM +0200, Ralf Wildenhues wrote:
> > > * Bob Rossi wrote on Sat, Apr 29, 2006 at 04:00:03AM CEST:
> > > > 
> > > > Can I do something in configure.in that says 
> > > >   if .. 
> > > >     AM_LIBTOOL
> > > >   fi;
> > > > 
> > > > or is this invalid?
> > > 
> > > This is invalid and will break at unfortunate places.
> 
> > Thanks for the advice. This was definatly a typo on my part. I'm using
> > AC_PROG_LIBTOOL.
> 
> > However, I was burned before by putting a macro in an 'if' statement.
> 
> Right.
> 
> > I was wondering if it was OK to use AC_PROG_LIBTOOL in an if
> > statement.
> 
> No.  To put it very explicitly: the code Russ posted may cause seemingly
> unrelated breakage.  You get to keep the pieces.  And yes, it also may
> "just happen to work".
> 
> One example for why it may break in really weird ways: say, you use two
> macros which both AC_REQUIRE([AC_PROG_SED]) (which is a realistic
> situation when Autoconf-2.60 and Libtool-2.0 are out).  Say
> AC_PROG_LIBTOOL happens to be used earlier in configure.ac, like this:
> 
>   if $whatever; then
>     AC_PROG_LIBTOOL
>   fi
> 
> then the expansion of AC_PROG_SED will happen right after the if
> condition.  The other macro that needs it, which, say, is called
> unconditionally, will assume AC_PROG_SED has already been expanded.
> But if $whatever turns out to be false, the corresponding code will
> not be run.
> 
> The AS_IF of Autoconf-2.60 will mediate this somewhat.  But until
> then I can only warn of such usage.

OK, so is the only safe way to do this to have 2 configure.in scripts?
One that uses AC_PROG_LIBTOOL and one that doesn't?

Or could I use m4 to bring in the macro definition or not, instead of
relying on the sh code?

Finally, I have a related question. I have a package that has a
--enable-tcl-extension feature. By default the package makes a static
library using AC_PROG_RANLIB. However, with --enable-tcl-extension, I 
need to make a .so, so that tcl can load it. I'm obviously thinking
about using AC_PROG_LIBTOOL to do this.

Does using LIBTOOL only effect the person trying to build a package from
source? Meaning, does it behave the same way as autoconf and automake? I
plan on installing libtool to develop the library. Then when I make a
release (make dist), the user will not have to have libtool installed, 
right? Currently my users do not need autoconf or automake installed to
build a dist that I have released.

Are there any disadvantages from switching to AC_PROG_LIBTOOL from
AC_PROG_RANLIB?

Also, when using AC_PROG_LIBTOOL, is there an easy way to force the
default behavior of building libraries to be static from within the
configure.in file?

Thanks,
Bob Rossi