From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1RWB7e-0004Oz-Uz for mharc-qemu-trivial@gnu.org; Thu, 01 Dec 2011 13:12:38 -0500 Received: from eggs.gnu.org ([140.186.70.92]:47125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWB7X-0003yj-MO for qemu-trivial@nongnu.org; Thu, 01 Dec 2011 13:12:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWB7T-0000Lf-EF for qemu-trivial@nongnu.org; Thu, 01 Dec 2011 13:12:31 -0500 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:54687) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWB7J-0000HI-Hh; Thu, 01 Dec 2011 13:12:17 -0500 Received: from localhost (v220110690675601.yourvserver.net.local [127.0.0.1]) by v220110690675601.yourvserver.net (Postfix) with ESMTP id 17D8F728188C; Thu, 1 Dec 2011 19:11:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at weilnetz.de Received: from v220110690675601.yourvserver.net ([127.0.0.1]) by localhost (v220110690675601.yourvserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmoKzvR+vPHR; Thu, 1 Dec 2011 19:11:25 +0100 (CET) Received: from flocke.weilnetz.de (p5086F501.dip.t-dialin.net [80.134.245.1]) by v220110690675601.yourvserver.net (Postfix) with ESMTPSA id AEA0B728188A; Thu, 1 Dec 2011 19:11:25 +0100 (CET) Received: from localhost ([127.0.0.1] ident=stefan) by flocke.weilnetz.de with esmtp (Exim 4.72) (envelope-from ) id 1RWB6I-00013M-TY; Thu, 01 Dec 2011 19:11:14 +0100 Message-ID: <4ED7C342.3060302@weilnetz.de> Date: Thu, 01 Dec 2011 19:11:14 +0100 From: Stefan Weil User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111110 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Stefano Stabellini References: <4ED3F1C3.4060601@weilnetz.de> <1322606869-25865-1-git-send-email-mdroth@linux.vnet.ibm.com> <1322606869-25865-2-git-send-email-mdroth@linux.vnet.ibm.com> <4ED68B19.7050704@weilnetz.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 78.47.199.172 Cc: "qemu-trivial@nongnu.org" , "qemu-devel@nongnu.org" Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH 2/2] Makefile: use full path for qapi-generated directory X-BeenThere: qemu-trivial@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 18:12:37 -0000 Am 01.12.2011 16:19, schrieb Stefano Stabellini: > On Wed, 30 Nov 2011, Stefan Weil wrote: >> It's common to use either out-of-tree builds or in-tree builds, >> but not to mix both variants with a common root directory. >> I think QEMU should explicitly forbid that mixed scenario (like >> other projects do). >> >> Even with your fix there can remain problems with generated >> header files. > > Really? Can you provide more specific details? Yes. Suppose different generated header files with the same name exist in the source directory tree and in the build directory tree. Then compiler options (the order of -I options) will determine which of two header files with same name will be used in out-of-tree builds. If the wrong one (that from the source directory tree) is used, the compiler might fail or produce wrong code (for example when macro values changed). >> The mixed scenario creates unnecessary complexity. >> Without the mixed scenario, your patch is not needed. > > I agree that supporting the mixed scenario shouldn't be a priority. > However without this last patch a "make clean" on the main tree is not > enough to allow out of tree builds. > > Try the following scenario: > > - cd qemu; ./configure; make > > - make clean > > - cd ../temp; ./configure --source-path=../qemu; make Which ./configure do you run in an empty temp directory? This example (like similar ones in your previous mail) won't work. > > this has to work, right? It does not without the patch to fix the > generation of config-devices.mak. No. You'll need a 'make distclean'. If that does what it should do, a following out-of-tree build will work. Regards, Stefan Weil From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWB7N-0003ou-Mt for qemu-devel@nongnu.org; Thu, 01 Dec 2011 13:12:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWB7J-0000JO-Nh for qemu-devel@nongnu.org; Thu, 01 Dec 2011 13:12:21 -0500 Message-ID: <4ED7C342.3060302@weilnetz.de> Date: Thu, 01 Dec 2011 19:11:14 +0100 From: Stefan Weil MIME-Version: 1.0 References: <4ED3F1C3.4060601@weilnetz.de> <1322606869-25865-1-git-send-email-mdroth@linux.vnet.ibm.com> <1322606869-25865-2-git-send-email-mdroth@linux.vnet.ibm.com> <4ED68B19.7050704@weilnetz.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH 2/2] Makefile: use full path for qapi-generated directory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: "qemu-trivial@nongnu.org" , Stefan Hajnoczi , Michael Roth , "qemu-devel@nongnu.org" Am 01.12.2011 16:19, schrieb Stefano Stabellini: > On Wed, 30 Nov 2011, Stefan Weil wrote: >> It's common to use either out-of-tree builds or in-tree builds, >> but not to mix both variants with a common root directory. >> I think QEMU should explicitly forbid that mixed scenario (like >> other projects do). >> >> Even with your fix there can remain problems with generated >> header files. > > Really? Can you provide more specific details? Yes. Suppose different generated header files with the same name exist in the source directory tree and in the build directory tree. Then compiler options (the order of -I options) will determine which of two header files with same name will be used in out-of-tree builds. If the wrong one (that from the source directory tree) is used, the compiler might fail or produce wrong code (for example when macro values changed). >> The mixed scenario creates unnecessary complexity. >> Without the mixed scenario, your patch is not needed. > > I agree that supporting the mixed scenario shouldn't be a priority. > However without this last patch a "make clean" on the main tree is not > enough to allow out of tree builds. > > Try the following scenario: > > - cd qemu; ./configure; make > > - make clean > > - cd ../temp; ./configure --source-path=../qemu; make Which ./configure do you run in an empty temp directory? This example (like similar ones in your previous mail) won't work. > > this has to work, right? It does not without the patch to fix the > generation of config-devices.mak. No. You'll need a 'make distclean'. If that does what it should do, a following out-of-tree build will work. Regards, Stefan Weil