Re: AM_CFLAGS and sub/foo.c
On Jun 15, 2001, "Steve M. Robbins" <[EMAIL PROTECTED]> wrote:
> I normally want the program-specific flags _in addition_ to the
> generic flags. So I *always* have $(LDADD) in $foo_LDADD.
But consider the case of not wanting $(LDADD) in foo_LDADD. Or
consider cases in which the order matters, and you need control over
where $(LDADD) appears in foo_LDADD. I think the only way to do this
right is to defer the decision to the user, which means not having it
included by default. Which is a good thing in itself, because it lets
one omit LDADD completely.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AM_CFLAGS and sub/foo.c
On Thu, Jun 14, 2001 at 06:51:09PM -0600, Tom Tromey wrote: > > "Steve" == Steve M Robbins <[EMAIL PROTECTED]> writes: > > Steve> Given the following Makefile.am > Steve>bin_PROGRAMS = foo > Steve>foo_SOURCES = foo.c sub/foo2.c > Steve> it turns out that "foo.c" is compiled using $(COMPILE), and hence > Steve> includes AM_CFLAGS. However, "foo2.c" is compiled *without* > Steve> AM_CFLAGS. > > Thanks for noticing this! > > What I intended is that by default everything is compiled with > AM_CFLAGS. But if there are per-executable CFLAGS in effect, then > AM_CFLAGS is omitted. So I agree you've found a bug. > > Your message, plus my recent adventures into automake.texi, make me > wonder if this is the best approach. It would certainly be easier to > document if AM_CFLAGS was simply always used. > > Now is the time to decide this sort of thing -- before 1.5 goes out. > Any comments? Reasons to prefer one over the other? As I recall I > planned it this way on the theory that adding AM_CFLAGS to the per-exe > CFLAGS is easy for the user, but removing it would be hard. So what you are saying is that AM_CFLAGS and foo_CFLAGS will behave like LDADD and foo_LDADD (i.e. setting the foo_ version overrides the other)? I've always found this a bit of a nuisance with LDADD, to be honest. I normally want the program-specific flags _in addition_ to the generic flags. So I *always* have $(LDADD) in $foo_LDADD. I see that you've already checked in a fix: thanks! -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: AM_CFLAGS and sub/foo.c
> "Steve" == Steve M Robbins <[EMAIL PROTECTED]> writes: Steve> The upshot is that "foo.c" is compiled using AM_CFLAGS but NOT Steve> foo_CFLAGS, while "foo2.c" is compiled NOT using AM_CFLAGS but using Steve> foo_CFLAGS. I'm checking in a fix for this. Tom
Re: AM_CFLAGS and sub/foo.c
> "Steve" == Steve M Robbins <[EMAIL PROTECTED]> writes: Steve> Given the following Makefile.am Steve> bin_PROGRAMS = foo Steve> foo_SOURCES = foo.c sub/foo2.c Steve> it turns out that "foo.c" is compiled using $(COMPILE), and hence Steve> includes AM_CFLAGS. However, "foo2.c" is compiled *without* Steve> AM_CFLAGS. Thanks for noticing this! What I intended is that by default everything is compiled with AM_CFLAGS. But if there are per-executable CFLAGS in effect, then AM_CFLAGS is omitted. So I agree you've found a bug. Your message, plus my recent adventures into automake.texi, make me wonder if this is the best approach. It would certainly be easier to document if AM_CFLAGS was simply always used. Now is the time to decide this sort of thing -- before 1.5 goes out. Any comments? Reasons to prefer one over the other? As I recall I planned it this way on the theory that adding AM_CFLAGS to the per-exe CFLAGS is easy for the user, but removing it would be hard. Tom
AM_CFLAGS and sub/foo.c
Hi, I'm quite confused by the behaviour of CVS automake and AM_CFLAGS. Given the following Makefile.am bin_PROGRAMS = foo foo_SOURCES = foo.c sub/foo2.c it turns out that "foo.c" is compiled using $(COMPILE), and hence includes AM_CFLAGS. However, "foo2.c" is compiled *without* AM_CFLAGS. Indeed, in automake's handle_languages(), "foo_CFLAGS" is explicitly substituted for AM_CFLAGS. The upshot is that "foo.c" is compiled using AM_CFLAGS but NOT foo_CFLAGS, while "foo2.c" is compiled NOT using AM_CFLAGS but using foo_CFLAGS. That strikes me as inconsistent. What is intended? It seems to me that AM_CFLAGS should always be there. Assuming this is true, I started a test case to detect when this is not true (attached). Regards, -Steve #! /bin/sh # Test that AM_ shadow variables are honoured. . $srcdir/defs || exit 1 cat >> configure.in << 'END' AC_PROG_CC AC_PROG_CXX END cat > Makefile.am << 'END' bin_PROGRAMS = foo bar foo_SOURCES = foo.c sub/foo2.c bar_SOURCES = bar.cc sub/bar2.cc END # Make sure `compile' is required. $ACLOCAL || exit 1 $AUTOMAKE || exit 1 : > compile $AUTOMAKE || exit 1 # Each line with variable VAR should have shadow variable AM_VAR # (assume they will appear on the same line) test "`grep '$(CPPFLAGS)' Makefile.in | grep -v '$(AM_CPPFLAGS)'`" && exit 1 test "`grep '$(CFLAGS)'Makefile.in | grep -v '$(AM_CFLAGS)'`"&& exit 1 test "`grep '$(LDFLAGS)' Makefile.in | grep -v '$(AM_LDFLAGS)'`" && exit 1 test "`grep '$(CXXFLAGS)' Makefile.in | grep -v '$(AM_CXXFLAGS)'`" && exit 1 test "`grep '$(OBJCFLAGS)' Makefile.in | grep -v '$(AM_OBJCFLAGS)'`" && exit 1 test "`grep '$(ASFLAGS)' Makefile.in | grep -v '$(AM_ASFLAGS)'`" && exit 1 test "`grep '$(FFLAGS)'Makefile.in | grep -v '$(AM_FFLAGS)'`"&& exit 1 test "`grep '$(RFLAGS)'Makefile.in | grep -v '$(AM_RFLAGS)'`"&& exit 1 test "`grep '$(GCJFLAGS)' Makefile.in | grep -v '$(AM_GCJFLAGS)'`" && exit 1 test "`grep '$(YFLAGS)'Makefile.in | grep -v '$(AM_YFLAGS)'`"&& exit 1 exit 0 -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
