From nobody Mon Feb 9 12:09:24 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1485956827113363.47586670757505; Wed, 1 Feb 2017 05:47:07 -0800 (PST) Received: from localhost ([::1]:51058 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYvFY-0007Tw-6L for importer@patchew.org; Wed, 01 Feb 2017 08:47:04 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYvDX-0006Id-56 for qemu-devel@nongnu.org; Wed, 01 Feb 2017 08:45:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYvDV-0004gM-Lm for qemu-devel@nongnu.org; Wed, 01 Feb 2017 08:44:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55128) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cYvDV-0004fC-Cf for qemu-devel@nongnu.org; Wed, 01 Feb 2017 08:44:57 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 81BDCC04B92A; Wed, 1 Feb 2017 13:44:57 +0000 (UTC) Received: from localhost (ovpn-116-240.ams2.redhat.com [10.36.116.240]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v11Diu6M024726; Wed, 1 Feb 2017 08:44:56 -0500 From: Stefan Hajnoczi To: Date: Wed, 1 Feb 2017 13:44:44 +0000 Message-Id: <20170201134453.11963-2-stefanha@redhat.com> In-Reply-To: <20170201134453.11963-1-stefanha@redhat.com> References: <20170201134453.11963-1-stefanha@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 01 Feb 2017 13:44:57 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 01/10] make: move top level dir to end of include search path X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefan Hajnoczi Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: "Daniel P. Berrange" Currently the search path is 1. source dir corresponding to input file (implicit by compiler) 2. top level build dir 3. top level source dir 4. top level source include/ dir 5. source dir corresponding to input file 6. build dir corresponding to output file Search item 5 is an effective no-op, since it duplicates item 1. When srcdir =3D=3D builddir, item 6 also duplicates item 1, which causes a semantic difference between VPATH and non-VPATH builds. Thus to ensure consistent semantics we need item 6 to be present immediately after item 1. e.g. 1. source dir corresponding to input file (implicit by compiler) 2. build dir corresponding to output file 3. top level build dir 4. top level source dir 5. top level source include/ dir When srcdir =3D=3D builddir, items 1 & 2 collapse into one, and items 3 & 4 collapse into one, but the overall search order is still consistent with srcdir !=3D builddir A further complication is that while most of the source files are built with a current directory of $BUILD_DIR, target dependant files are built with a current directory of $BUILD_DIR/$TARGET. As a result, search item 2 resolves to a different location for target independant vs target dependant files. For example when building 'migration/ram.o', the use of '-I$(@D)' (which expands to '-Imigration') would not find '$BUILD_DIR/migration', but rather '$BUILD_DIR/$TARGET/migration'. If there are generated headers files to be used by the migration code in '$BUILD_DIR/migration', these will not be found by the relative include, an absolute include is needed instead. This has not been a problem so far, since nothing has been generating headers in sub-dirs, but the trace code will shortly be doing that. So it is needed to list '-I$(BUILD_DIR)/$(@D)' as well as '-I$(@D)' to ensure both directories are searched when building target dependant code. So the search order ends up being: 1. source dir corresponding to input file (implicit by compiler) 2. build dir corresponding to output file (absolute) 3. build dir corresponding to output file (relative to cwd) 4. top level build dir 5. top level source dir 6. top level source include/ dir One final complication is that the absolute '-I$(BUILD_DIR)/$(@D)' will sometimes end up pointing to a non-existant directory if that sub-dir does not have any target-independant files to be built. Rather than try to dynamically filter this, a simple 'mkdir' ensures $(BUILD_DIR)/$(@D) is guaranteed to exist at all times. Signed-off-by: Daniel P. Berrange Reviewed-by: Eric Blake Message-id: 20170125161417.31949-2-berrange@redhat.com Signed-off-by: Stefan Hajnoczi --- rules.mak | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/rules.mak b/rules.mak index d5c516c..575a3af 100644 --- a/rules.mak +++ b/rules.mak @@ -26,8 +26,13 @@ QEMU_CXXFLAGS =3D -D__STDC_LIMIT_MACROS $(filter-out -Ws= trict-prototypes -Wmissing # Flags for dependency generation QEMU_DGFLAGS +=3D -MMD -MP -MT $@ -MF $(@D)/$(*F).d =20 -# Same as -I$(SRC_PATH) -I., but for the nested source/object directories -QEMU_INCLUDES +=3D -I$(