From patchwork Wed Jan 25 16:14:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= X-Patchwork-Id: 719728 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3v7qz81NM2z9sD6 for ; Thu, 26 Jan 2017 03:20:36 +1100 (AEDT) Received: from localhost ([::1]:60940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cWQJF-0007zM-G3 for incoming@patchwork.ozlabs.org; Wed, 25 Jan 2017 11:20:33 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cWQDM-0001uY-Vr for qemu-devel@nongnu.org; Wed, 25 Jan 2017 11:14:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cWQDL-0003U8-LY for qemu-devel@nongnu.org; Wed, 25 Jan 2017 11:14:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47786) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cWQDL-0003U0-D8 for qemu-devel@nongnu.org; Wed, 25 Jan 2017 11:14:27 -0500 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 99FD6C04B93E; Wed, 25 Jan 2017 16:14:27 +0000 (UTC) Received: from t460.redhat.com (ovpn-117-120.ams2.redhat.com [10.36.117.120]) by smtp.corp.redhat.com (Postfix) with ESMTP id 01E1A1CAE06; Wed, 25 Jan 2017 16:14:24 +0000 (UTC) From: "Daniel P. Berrange" To: qemu-devel@nongnu.org Date: Wed, 25 Jan 2017 16:14:10 +0000 Message-Id: <20170125161417.31949-2-berrange@redhat.com> In-Reply-To: <20170125161417.31949-1-berrange@redhat.com> References: <20170125161417.31949-1-berrange@redhat.com> X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 25 Jan 2017 16:14:27 +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] [PATCH v4 1/8] 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: Paolo Bonzini , =?UTF-8?q?Llu=C3=ADs=20Vilanova?= , Stefan Hajnoczi Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 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 == 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 == builddir, items 1 & 2 collapse into one, and items 3 & 4 collapse into one, but the overall search order is still consistent with srcdir != 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 --- 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 = -D__STDC_LIMIT_MACROS $(filter-out -Wstrict-prototypes -Wmissing # Flags for dependency generation QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(@D)/$(*F).d -# Same as -I$(SRC_PATH) -I., but for the nested source/object directories -QEMU_INCLUDES += -I$(