[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:18:54 -0400 |
User-agent: |
Mutt/1.5.9i |
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
- conditionally using libtool, Bob Rossi, 2006/04/28
- Re: conditionally using libtool, Russ Allbery, 2006/04/29
- Re: conditionally using libtool, Ralf Wildenhues, 2006/04/29
- Re: conditionally using libtool, Bob Rossi, 2006/04/29
- Re: conditionally using libtool, Ralf Wildenhues, 2006/04/29
- Re: conditionally using libtool,
Bob Rossi <=
- Re: conditionally using libtool, Ralf Wildenhues, 2006/04/29
- Re: conditionally using libtool, Bob Rossi, 2006/04/29
- Re: conditionally using libtool, Russ Allbery, 2006/04/29
- Re: conditionally using libtool, Ralf Wildenhues, 2006/04/30
- Re: conditionally using libtool, Russ Allbery, 2006/04/30