Automatic regeneration of libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The libtool manual currently states: ~ This macro also sets the shell variable LIBTOOL_DEPS, that you can ~ use to automatically update the libtool script if it becomes ~ out-of-date. In order to do that, add to your `configure.in': ~ LT_INIT ~ AC_SUBST(LIBTOOL_DEPS) ~ and, to `Makefile.in' or `Makefile.am': ~ LIBTOOL_DEPS = @LIBTOOL_DEPS@ ~ libtool: $(LIBTOOL_DEPS) ~ $(SHELL) ./config.status --recheck ~ If you are using GNU automake, you can omit the assignment, as ~ automake will take care of it. You'll obviously have to create ~ some dependency on `libtool'. Instead, I'd like to have LT_INIT perform the AC_SUBST([LIBTOOL_DEPS]), and Automake generate the following rule when libtool is in use: $(LIBTOOL): $(top_builddir)/config.status $(LIBTOOL_DEPS) cd $(top_builddir) $(SHELL) ./config.status $@ Does that seem like a sensible thing to want? Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAO5fJFRMICSmD1gYRAitFAJ4tGZdyPUdFfgS2CAtJ2vAayniwLwCeLTpi aKRe1g3IXj0+8CXms+xZPlY= =mJvA -END PGP SIGNATURE-
Target-specific CFLAGS
Hi, everyone, A couple of weeks back I posted my problems with getting an ancient version of Automake to build two libraries. Each was to use the same source but one should have it's objects compiled with -DFEATURE. I attempted to use the following setup: quote noinst_LIBRARIES = normal.a normal-feature.a normal_a_SOURCES = [bunch of files] normal_feature_a_SOURCES = $(normal_a_SOURCES) normal_feature_a_CFLAGS = -DFEATURE /quote While this didn't work on my old version of Automake, I was told that upgrading to the most recent version (1.8.2) would fix this problem. It doesn't. The second library is compiled using the object files created for the first library. In other words, -DFEATURE is never specified in the compilation of the objects needed for the extra library and I get two copies of the same library (with different names). Where have I gone wrong? Thanks, Scott
RE: Target-specific CFLAGS
From: [EMAIL PROTECTED] quote noinst_LIBRARIES = normal.a normal-feature.a normal_a_SOURCES = [bunch of files] normal_feature_a_SOURCES = $(normal_a_SOURCES) normal_feature_a_CFLAGS = -DFEATURE /quote ... Where have I gone wrong? Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. Sorry for the mails, all. Scott
Re: Target-specific CFLAGS
Drummonds, Scott B [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] quote noinst_LIBRARIES = normal.a normal-feature.a normal_a_SOURCES = [bunch of files] normal_feature_a_SOURCES = $(normal_a_SOURCES) normal_feature_a_CFLAGS = -DFEATURE /quote ... Where have I gone wrong? Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
RE: Target-specific CFLAGS
I didn't. But I do now. Thanks, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Pfaff Sent: Tuesday, February 24, 2004 1:43 PM To: [EMAIL PROTECTED] Subject: Re: Target-specific CFLAGS Drummonds, Scott B [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] quote noinst_LIBRARIES = normal.a normal-feature.a normal_a_SOURCES = [bunch of files] normal_feature_a_SOURCES = $(normal_a_SOURCES) normal_feature_a_CFLAGS = -DFEATURE /quote ... Where have I gone wrong? Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: Target-specific CFLAGS
On Tue, 24 Feb 2004, Ben Pfaff wrote: Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? This distinction is not entirely correct since CPPFLAGS is normally supplied to the C++ compiler as well. CFLAGS is for the C compiler and CXXFLAGS is for the C++ compiler. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Target-specific CFLAGS
Bob Friesenhahn [EMAIL PROTECTED] writes: On Tue, 24 Feb 2004, Ben Pfaff wrote: Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? This distinction is not entirely correct since CPPFLAGS is normally supplied to the C++ compiler as well. CFLAGS is for the C compiler and CXXFLAGS is for the C++ compiler. Well, yes: C++ uses the C preprocessor. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: Target-specific CFLAGS
On Tue, 24 Feb 2004, Ben Pfaff wrote: Bob Friesenhahn [EMAIL PROTECTED] writes: On Tue, 24 Feb 2004, Ben Pfaff wrote: Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? This distinction is not entirely correct since CPPFLAGS is normally supplied to the C++ compiler as well. CFLAGS is for the C compiler and CXXFLAGS is for the C++ compiler. Well, yes: C++ uses the C preprocessor. Which is not really a great assumption since C++ is a different language and the C++ compiler vendor may not be the same as the C compiler vendor. The behavior of the C++ preprocessing may behave differently. Autoconf and Automake make a lot of assumptions when it comes to C++. Luckily the assumptions are correct more often than not. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Extra recursive targets
Is there a way to add additional recursive targets to a makefile? I tried to use RECURSIVE_TARGETS += foo-recursive but automake complains about the use of `+='. When changing that to a simple `=' the generated makefile has only foo-recursive as RECURSIVE_TARGETS. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.