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