Re: conditionally using libtool

[Ralf Wildenhues]

* Bob Rossi wrote on Sat, Apr 29, 2006 at 06:18:54PM CEST:
> 
> 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?

I don't see why that would be necessary.  Unless you need to avoid the
Automake adjustments it does for Libtool.

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

Yes, that would help around the AC_REQUIREd-macros problem.

This is exactly the effect of AS_IF, only that, unfortunately the AS_IF
of Autoconf-2.59 has been m4_define'd and not AC_DEFUN'ed, so that it
does not help in this regard.  For example, you could

AC_DEFINE([br_CHOOSE_LIBBUILD],
[if $condition; then
  AC_PROG_LIBTOOL
fi])

and then invoke br_CHOOSE_LIBBUILD later; that will ensure required
macros are expanded before that.

> 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?

Correct.  That's the usual way.

> Currently my users do not need autoconf or automake installed to
> build a dist that I have released.

Right.

> Are there any disadvantages from switching to AC_PROG_LIBTOOL from
> AC_PROG_RANLIB?

A lot larger configure script?  Somewhat longer configure execution
time?  (Others will be able to make this list a lot longer..)

> 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?

Yes.  Before AC_PROG_LIBTOOL, call AC_DISABLE_SHARED.  (In the macro
example above, you'd need to call it _before_, thus outside of
br_CHOOSE_LIBBUILD.)

Cheers,
Ralf