[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Override... but not really
From: |
Philip Prindeville |
Subject: |
Re: Override... but not really |
Date: |
Mon, 09 Aug 2010 11:08:22 -0700 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 |
Sorry, I sent that off and then realized that a little context might be more
useful.
I do a lot of cross-compilation, where the platform requires a set of CFLAGS to
always be present, such as -march=xxx and -isysroot=yyyy ...
The problem is that if you pass these in from the command line as "make -C foobar
CFLAGS=..." then any CFLAGS that the package tries to build (either in its top-level
or submake) makefiles gets ignored.
I'm trying to come up with guidelines for writing cross-compilation friendly makefiles,
but the behavior of "override" not re-exporting itself makes this a little
tricky.
Looking for some insight.
Thanks.
On 8/9/10 10:00 AM, Philip Prindeville wrote:
Is this expected behavior?
$ cat makefile1
override CFLAGS+=-DB
$(info makefile1: CFLAGS=$(CFLAGS))
all:
make -f makefile2
$ cat makefile2
$(info makefile2: CFLAGS=$(CFLAGS))
override CFLAGS+=-DC
$(info makefile2: CFLAGS=$(CFLAGS))
all:
@echo foo
$ make -f makefile1 CFLAGS=-DA
makefile1: CFLAGS=-DA -DB
make -f makefile2
makefile2: CFLAGS=-DA
makefile2: CFLAGS=-DA -DC
foo
$
So why isn't the CFLAGS that gets passed to the submake set to "-DA -DB"?
This is less than intuitive: it's not *really* overriding if it's only
semi-persistent.
What's even more confusing is that make apparently keeps two copies... the one
that's in-scope for the current make, and the one that gets re-exported into
sub-makes.
I couldn't find in the documentation where this behavior gets called out.
-Philip
- Override... but not really, Philip Prindeville, 2010/08/09
- Re: Override... but not really, Paul Smith, 2010/08/09
- Re: Override... but not really, Philip Prindeville, 2010/08/09
- Re: Override... but not really, Paul Smith, 2010/08/09
- Re: Override... but not really, Philip Prindeville, 2010/08/09
- Re: Override... but not really, Paul Smith, 2010/08/09
- Re: Override... but not really, Philip Prindeville, 2010/08/09
- Re: Override... but not really, Paul Smith, 2010/08/09
- Re: Override... but not really, Philip Prindeville, 2010/08/09
Re: Override... but not really,
Philip Prindeville <=