From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mm8Im-0000BM-N0 for qemu-devel@nongnu.org; Fri, 11 Sep 2009 11:44:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mm8Ii-000080-43 for qemu-devel@nongnu.org; Fri, 11 Sep 2009 11:44:44 -0400 Received: from [199.232.76.173] (port=35772 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mm8Ih-00007w-SL for qemu-devel@nongnu.org; Fri, 11 Sep 2009 11:44:39 -0400 Received: from mail.corp.accelance.fr ([213.162.48.15]:52096) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mm8Ih-0003lM-Fl for qemu-devel@nongnu.org; Fri, 11 Sep 2009 11:44:39 -0400 From: Thomas Monjalon Date: Fri, 11 Sep 2009 17:44:36 +0200 References: <200909092236.n89MaDVS020267@d01av01.pok.ibm.com> <4AA85BAD.2000802@us.ibm.com> In-Reply-To: <4AA85BAD.2000802@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909111744.37066.thomas@monjalon.net> 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: qemu-devel@nongnu.org Cc: Anthony Liguori , Juan Quintela 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. -- Thomas