On Fri, 25 Jan 2008 14:39:57 +, Paul Brook [EMAIL PROTECTED] said:
Saying CPPFLAGS+= is much more convenient if for any reason the
external build environment would like to pass unusual CPPFLAGS.
Paul No. This doesn't do what you thing it does. The most common way
Paul of
Ronan Keryell wrote:
On Fri, 25 Jan 2008 14:39:57 +, Paul Brook [EMAIL PROTECTED] said:
Saying CPPFLAGS+= is much more convenient if for any reason the
external build environment would like to pass unusual CPPFLAGS.
Paul No. This doesn't do what you thing it does. The
Paul Brook writes (Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target):
Huh? No it doesn't. config-host.mak contains
CPPFLAGS=
then Makefile.target contains
CPPFLAGS+=whatever
It doesn't seem to on my build.
Why don't you just put your custom flags in CFLAGS, not CPPFLAGS?
The former
Why don't you just put your custom flags in CFLAGS, not CPPFLAGS?
The former is deliberately left for the user to override.
Several (but not all AFAICT) of the target subdirectory Makefiles set
CFLAGS.
Really? Which ones?
Paul
Paul Brook writes (Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target):
Really? Which ones?
tests/Makefile and tests/cris/Makefile do. Not that they're
particularly important. I also saw Makefile.target's if'd out change
to CFLAGS near at the bottom by the audio .o's, but of course that's
What I mean is: if you want
for any reason to build qemu in a weird way then you're going to have
to edit config-host.mak (or somewhere similar) in any case. You
probably want to set some CPPFLAGS as well as various other things.
If you do this at the moment then you have to reproduce all of
Saying CPPFLAGS+= is much more convenient if for any reason the
external build environment would like to pass unusual CPPFLAGS.
Regards,
Ian.
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving
Saying CPPFLAGS+= is much more convenient if for any reason the
external build environment would like to pass unusual CPPFLAGS.
No. This doesn't do what you thing it does.
The most common way of overriding these variables is to pass them on the
commandline, i.e. make CPPFLAGS=-blah. This
Paul Brook writes (Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target):
No. This doesn't do what you thing it does.
The most common way of overriding these variables is to pass them on the
commandline, i.e. make CPPFLAGS=-blah. This overrides all assignments to
that variable including
iwj writes (Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target):
Paul Brook writes (Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target):
No. This doesn't do what you thing it does.
The most common way of overriding these variables is to pass them on the
commandline, i.e. make
Paul Brook writes (Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target):
On Friday 25 January 2008, Ian Jackson wrote:
What circumstances ? CPPFLAGS+= overrides (discards) values in the
environment as well as ones from the command line.
[ demonstration ]
Oh, err, looks like I messed
Paul Brook writes (Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target):
In that case you should always provide a definition in config-host.mak.
Under some circumstances make may inherit initial values from elsewhere.
What circumstances ? CPPFLAGS+= overrides (discards) values
Providing a definition in config-host.mak involves duplicating the
value, which can't be right.
Huh? No it doesn't. config-host.mak contains
CPPFLAGS=
then Makefile.target contains
CPPFLAGS+=whatever
If there's no other way to do it then
there should be a reference to USER_CPPFLAGS or
13 matches
Mail list logo
