autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: conditionally using libtool


From: Bob Rossi
Subject: Re: conditionally using libtool
Date: Sat, 29 Apr 2006 12:46:15 -0400
User-agent: Mutt/1.5.9i

On Sat, Apr 29, 2006 at 06:34:59PM +0200, Ralf Wildenhues wrote:
> * 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.)

Wow, thanks for answering all my questions! I'm going to switch over to
libtool. It really does seem like the way to go.

Thanks,
Bob Rossi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]