From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mm8Su-0004tz-LS for qemu-devel@nongnu.org; Fri, 11 Sep 2009 11:55:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mm8Sq-0004n6-SM for qemu-devel@nongnu.org; Fri, 11 Sep 2009 11:55:12 -0400 Received: from [199.232.76.173] (port=54688 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mm8Sq-0004mk-LR for qemu-devel@nongnu.org; Fri, 11 Sep 2009 11:55:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27426) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mm8Sq-0005Sg-5r for qemu-devel@nongnu.org; Fri, 11 Sep 2009 11:55:08 -0400 From: Juan Quintela In-Reply-To: <200909111744.37066.thomas@monjalon.net> (Thomas Monjalon's message of "Fri, 11 Sep 2009 17:44:36 +0200") References: <200909092236.n89MaDVS020267@d01av01.pok.ibm.com> <4AA85BAD.2000802@us.ibm.com> <200909111744.37066.thomas@monjalon.net> Date: Fri, 11 Sep 2009 17:52:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [COMMIT 8a2e6ab] Remove CFLAGS parameter in cc-option List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Monjalon Cc: Anthony Liguori , qemu-devel@nongnu.org Thomas Monjalon wrote: > Anthony Liguori wrote: >> Juan Quintela wrote: >> > malc wrote: >> >> On Thu, 10 Sep 2009, Juan Quintela wrote: >> >>> malc wrote: >> >>>> On Wed, 9 Sep 2009, Anthony Liguori wrote: >> >>>>> From: Juan Quintela >> >>>>> >> >>>>> 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.