qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [COMMIT 8a2e6ab] Remove CFLAGS parameter in cc-option


From: Juan Quintela
Subject: [Qemu-devel] Re: [COMMIT 8a2e6ab] Remove CFLAGS parameter in cc-option
Date: Fri, 11 Sep 2009 17:52:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Thomas Monjalon <address@hidden> wrote:
> Anthony Liguori wrote:
>> Juan Quintela wrote:
>> > malc <address@hidden> wrote:
>> >> On Thu, 10 Sep 2009, Juan Quintela wrote:
>> >>> malc <address@hidden> wrote:
>> >>>> On Wed, 9 Sep 2009, Anthony Liguori wrote:
>> >>>>> From: Juan Quintela <address@hidden>
>> >>>>>
>> >>>>> With cc-option we are testing if gcc just accept a particular option,
>> >>>>> we don't need CFLAGS at all.  And this fixes the recursive problem
>> >>>>> with CFLAGS
>> >>>>
>> >>>> This is nonsense, previous options, those in CFLAGS, might conflict
>> >>>> with the new ones.
>> >>>
>> >>> The only thing that we are testing is if gcc support that _option_
>> >>>
>> >>> What is the use case tat you have in mind?  A first grep on gcc man
>> >>> page don't show options that conflict with each other.
>> >>
>> >> If you want artificial exmaples i can come up with plenty, and from the
>> >> top of my head -m486 with -msse2 are quite incompatible with each other,
>> >> furthermore, point is this - testing one option in isolation is broken.
>> >
>> > Ok. For the case that we were using, it don't matter at all.  But in
>> > general, there "could" (it is only one cc-option call in all sources).
>> >
>> > Anthony, what do you preffer:
>> > - revert the patch and add another one that changes += by :=
>>
>> No, I don't want to revert this patch and switch to :=.  += should
>> work.  I don't understand why it doesn't.
>>
>> What I'd prefer is for someone to figure out the root cause of += not
>> working for us.  If we can't, I'd like a big fat comment stating that
>> it's a known deficiency and we'll move on.
>
> "make" complains about an infinite recursive assignment because the first 
> assignment of CFLAGS defines a recursively-expanded variable and the right 
> value is a macro which uses the CFLAGS.
>
> As explained in 
> http://www.gnu.org/software/make/manual/html_node/Appending.html , it can be 
> fixed by making CFLAGS a simply-expanded variable at its first assignment.
>
> I have submitted a patch.

Thanks for the explanation.
I haven't yet seen your patch, but I agree that right thing to do is
do the 1st assignment as QEMU_CFLAGS := foo

We can't really use CFLAGS, because CFLAGS need to work from the command
line

make CFLAGS="-O0 -g"

or I am lossing something obvious?

Later, Juan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]