From ba78db44f6532d66a1e704bd44613e841baa2fc5 Mon Sep 17 00:00:00 2001 From: "Daniel P. Berrange" Date: Wed, 25 Jan 2017 16:14:10 +0000 Subject: make: move top level dir to end of include search path 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 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 d5c516caff..575a3afdff 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$(