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 thin
> 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 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 t
> > 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"):
> 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 cus
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.
>
> [ demonst
> 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
On Friday 25 January 2008, Ian Jackson wrote:
> 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
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 (discard
> 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 al
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 t
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 a
> 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 ov
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 revisi
14 matches
Mail list logo
