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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
