2009-01-21 21:12:52 +03:00
|
|
|
|
2018-05-21 13:35:04 +03:00
|
|
|
# These are used when we want to do substitutions without confusing Make
|
|
|
|
NULL :=
|
|
|
|
SPACE := $(NULL) #
|
2016-06-01 07:25:15 +03:00
|
|
|
COMMA := ,
|
|
|
|
|
2009-10-06 23:11:14 +04:00
|
|
|
# Don't use implicit rules or variables
|
|
|
|
# we have explicit rules for everything
|
|
|
|
MAKEFLAGS += -rR
|
|
|
|
|
|
|
|
# Files with this suffixes are final, don't try to generate them
|
|
|
|
# using implicit rules
|
2016-11-02 22:46:13 +03:00
|
|
|
%/trace-events:
|
|
|
|
%.hx:
|
|
|
|
%.py:
|
|
|
|
%.objs:
|
2009-10-06 23:11:14 +04:00
|
|
|
%.d:
|
|
|
|
%.h:
|
|
|
|
%.c:
|
2014-02-05 21:27:27 +04:00
|
|
|
%.cc:
|
2013-08-07 19:39:36 +04:00
|
|
|
%.cpp:
|
2009-10-06 23:11:14 +04:00
|
|
|
%.m:
|
|
|
|
%.mak:
|
|
|
|
|
2009-11-19 22:07:52 +03:00
|
|
|
# Flags for dependency generation
|
2015-08-09 12:39:53 +03:00
|
|
|
QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(@D)/$(*F).d
|
2009-10-11 17:08:57 +04:00
|
|
|
|
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 <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25 19:14:10 +03:00
|
|
|
# Compiler searches the source file dir first, but in vpath builds
|
|
|
|
# we need to make it search the build dir too, before any other
|
|
|
|
# explicit search paths. There are two search locations in the build
|
|
|
|
# dir, one absolute and the other relative to the compiler working
|
|
|
|
# directory. These are the same for target-independent files, but
|
|
|
|
# different for target-dependent ones.
|
2020-08-19 15:44:56 +03:00
|
|
|
QEMU_LOCAL_INCLUDES = -iquote $(BUILD_DIR) -iquote $(BUILD_DIR)/$(@D) -iquote $(@D)
|
2012-09-17 12:21:52 +04:00
|
|
|
|
2019-07-16 11:30:43 +03:00
|
|
|
WL := -Wl,
|
|
|
|
ifdef CONFIG_DARWIN
|
|
|
|
whole-archive = $(WL)-force_load,$1
|
|
|
|
else
|
|
|
|
whole-archive = $(WL)--whole-archive $1 $(WL)--no-whole-archive
|
|
|
|
endif
|
|
|
|
|
2019-12-12 15:30:36 +03:00
|
|
|
extract-libs = $(strip $(foreach o,$1,$($o-libs)))
|
2014-02-10 10:48:53 +04:00
|
|
|
|
2010-01-06 22:24:05 +03:00
|
|
|
%.o: %.c
|
2019-08-27 20:57:39 +03:00
|
|
|
@mkdir -p $(dir $@)
|
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 <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25 19:14:10 +03:00
|
|
|
$(call quiet-command,$(CC) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
|
|
|
|
$(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) \
|
|
|
|
-c -o $@ $<,"CC","$(TARGET_DIR)$@")
|
2009-01-21 21:12:52 +03:00
|
|
|
|
2014-02-05 21:27:27 +04:00
|
|
|
# If we have a CXX we might have some C++ objects, in which case we
|
|
|
|
# must link with the C++ compiler, not the plain C compiler.
|
|
|
|
LINKPROG = $(or $(CXX),$(CC))
|
|
|
|
|
build-sys: clean up flags included in the linker command line
Some of the CFLAGS that are discovered during configure, for example
compiler warnings, are being included on the linker command line because
QEMU_CFLAGS is added to it. Other flags, such as the -m32, appear twice
because they are included in both QEMU_CFLAGS and LDFLAGS. All this
leads to confusion with respect to what goes in which Makefile variables
(and we have plenty).
So, introduce QEMU_LDFLAGS for flags discovered by configure, following
the lead of QEMU_CFLAGS, and stop adding to it:
1) options that are already in CFLAGS, for example "-g"
2) duplicate options
At the same time, options that _are_ needed by both compiler and linker
must now be added to both QEMU_CFLAGS and QEMU_LDFLAGS, which is clearer.
This is mostly -fsanitize options. For now, --extra-cflags has this behavior
(but --extra-cxxflags does not).
Meson will not include CFLAGS on the linker command line, do the same in our
build system as well.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-12-11 17:34:27 +03:00
|
|
|
LINK = $(call quiet-command, $(LINKPROG) $(CFLAGS) $(QEMU_LDFLAGS) -o $@ \
|
2019-12-12 15:30:36 +03:00
|
|
|
$(filter-out %.a %.fa,$1) \
|
|
|
|
$(foreach l,$(filter %.fa,$1),$(call whole-archive,$l)) \
|
|
|
|
$(filter %.a,$1) \
|
2019-09-04 15:51:52 +03:00
|
|
|
$(call extract-libs,$1) $(LIBS),"LINK","$(TARGET_DIR)$@")
|
2011-05-15 12:51:28 +04:00
|
|
|
|
2016-06-23 20:39:18 +03:00
|
|
|
%.o: %.S
|
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 <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25 19:14:10 +03:00
|
|
|
$(call quiet-command,$(CCAS) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
|
|
|
|
$(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) \
|
|
|
|
-c -o $@ $<,"CCAS","$(TARGET_DIR)$@")
|
2009-01-21 21:12:52 +03:00
|
|
|
|
2014-02-05 21:27:27 +04:00
|
|
|
%.o: %.cc
|
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 <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25 19:14:10 +03:00
|
|
|
$(call quiet-command,$(CXX) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
|
2020-02-03 17:22:17 +03:00
|
|
|
$(QEMU_CXXFLAGS) $(QEMU_DGFLAGS) $(CXXFLAGS) $($@-cflags) \
|
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 <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25 19:14:10 +03:00
|
|
|
-c -o $@ $<,"CXX","$(TARGET_DIR)$@")
|
2014-02-05 21:27:27 +04:00
|
|
|
|
2013-08-07 19:39:36 +04:00
|
|
|
%.o: %.cpp
|
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 <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25 19:14:10 +03:00
|
|
|
$(call quiet-command,$(CXX) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
|
2020-02-03 17:22:17 +03:00
|
|
|
$(QEMU_CXXFLAGS) $(QEMU_DGFLAGS) $(CXXFLAGS) $($@-cflags) \
|
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 <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25 19:14:10 +03:00
|
|
|
-c -o $@ $<,"CXX","$(TARGET_DIR)$@")
|
2013-08-07 19:39:36 +04:00
|
|
|
|
2009-01-21 21:12:52 +03:00
|
|
|
%.o: %.m
|
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 <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25 19:14:10 +03:00
|
|
|
$(call quiet-command,$(OBJCC) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
|
|
|
|
$(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) \
|
|
|
|
-c -o $@ $<,"OBJC","$(TARGET_DIR)$@")
|
2009-01-21 21:12:52 +03:00
|
|
|
|
2012-12-21 12:23:18 +04:00
|
|
|
%.o: %.dtrace
|
2016-10-04 19:27:21 +03:00
|
|
|
$(call quiet-command,dtrace -o $@ -G -s $<,"GEN","$(TARGET_DIR)$@")
|
2012-12-21 12:23:18 +04:00
|
|
|
|
2014-02-10 10:48:56 +04:00
|
|
|
.PHONY: modules
|
|
|
|
modules:
|
|
|
|
|
2009-01-21 21:13:02 +03:00
|
|
|
%$(EXESUF): %.o
|
2019-12-12 15:30:36 +03:00
|
|
|
$(call LINK,$(filter %.o %.a %.fa, $^))
|
2009-01-21 21:13:09 +03:00
|
|
|
|
2009-01-21 21:13:16 +03:00
|
|
|
%.a:
|
2016-10-04 19:27:21 +03:00
|
|
|
$(call quiet-command,rm -f $@ && $(AR) rcs $@ $^,"AR","$(TARGET_DIR)$@")
|
2009-01-21 21:13:16 +03:00
|
|
|
|
2016-10-04 19:27:21 +03:00
|
|
|
# Usage: $(call quiet-command,command and args,"NAME","args to print")
|
|
|
|
# This will run "command and args", and either:
|
|
|
|
# if V=1 just print the whole command and args
|
|
|
|
# otherwise print the 'quiet' output in the format " NAME args to print"
|
|
|
|
# NAME should be a short name of the command, 7 letters or fewer.
|
|
|
|
# If called with only a single argument, will print nothing in quiet mode.
|
2018-11-29 20:45:31 +03:00
|
|
|
quiet-command-run = $(if $(V),,$(if $2,printf " %-7s %s\n" $2 $3 && ))$1
|
|
|
|
quiet-@ = $(if $(V),,@)
|
|
|
|
quiet-command = $(quiet-@)$(call quiet-command-run,$1,$2,$3)
|
2009-07-21 16:11:18 +04:00
|
|
|
|
|
|
|
# cc-option
|
2009-08-31 02:48:45 +04:00
|
|
|
# Usage: CFLAGS+=$(call cc-option, -falign-functions=0, -malign-functions=0)
|
2009-07-21 16:11:18 +04:00
|
|
|
|
2009-09-11 20:45:40 +04:00
|
|
|
cc-option = $(if $(shell $(CC) $1 $2 -S -o /dev/null -xc /dev/null \
|
|
|
|
>/dev/null 2>&1 && echo OK), $2, $3)
|
2016-07-20 22:36:49 +03:00
|
|
|
cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
|
|
|
|
>/dev/null 2>&1 && echo OK), $2, $3)
|
2009-10-07 04:40:58 +04:00
|
|
|
|
2019-05-24 16:09:42 +03:00
|
|
|
VPATH_SUFFIXES = %.c %.h %.S %.cc %.cpp %.m %.mak %.texi %.sh %.rc Kconfig% %.json.in
|
2010-04-27 01:52:23 +04:00
|
|
|
set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath $(PATTERN) $1)))
|
2009-12-21 12:06:55 +03:00
|
|
|
|
2014-06-22 10:55:23 +04:00
|
|
|
# install-prog list, dir
|
|
|
|
define install-prog
|
|
|
|
$(INSTALL_DIR) "$2"
|
|
|
|
$(INSTALL_PROG) $1 "$2"
|
|
|
|
$(if $(STRIP),$(STRIP) $(foreach T,$1,"$2/$(notdir $T)"),)
|
|
|
|
endef
|
|
|
|
|
2013-09-13 21:25:51 +04:00
|
|
|
# Logical functions (for operating on y/n values like CONFIG_FOO vars)
|
|
|
|
# Inputs to these must be either "y" (true) or "n" or "" (both false)
|
|
|
|
# Output is always either "y" or "n".
|
|
|
|
# Usage: $(call land,$(CONFIG_FOO),$(CONFIG_BAR))
|
|
|
|
# Logical NOT
|
|
|
|
lnot = $(if $(subst n,,$1),n,y)
|
|
|
|
# Logical AND
|
|
|
|
land = $(if $(findstring yy,$1$2),y,n)
|
|
|
|
# Logical OR
|
|
|
|
lor = $(if $(findstring y,$1$2),y,n)
|
|
|
|
# Logical XOR (note that this is the inverse of leqv)
|
|
|
|
lxor = $(if $(filter $(call lnot,$1),$(call lnot,$2)),n,y)
|
|
|
|
# Logical equivalence (note that leqv "","n" is true)
|
|
|
|
leqv = $(if $(filter $(call lnot,$1),$(call lnot,$2)),y,n)
|
|
|
|
# Logical if: like make's $(if) but with an leqv-like test
|
|
|
|
lif = $(if $(subst n,,$1),$2,$3)
|
|
|
|
|
2013-09-13 21:25:52 +04:00
|
|
|
# String testing functions: inputs to these can be any string;
|
|
|
|
# the output is always either "y" or "n". Leading and trailing whitespace
|
|
|
|
# is ignored when comparing strings.
|
|
|
|
# String equality
|
|
|
|
eq = $(if $(subst $2,,$1)$(subst $1,,$2),n,y)
|
|
|
|
# String inequality
|
|
|
|
ne = $(if $(subst $2,,$1)$(subst $1,,$2),y,n)
|
|
|
|
# Emptiness/non-emptiness tests:
|
|
|
|
isempty = $(if $1,n,y)
|
|
|
|
notempty = $(if $1,y,n)
|
|
|
|
|
2013-01-15 15:27:54 +04:00
|
|
|
.PHONY: clean-timestamp
|
|
|
|
clean-timestamp:
|
|
|
|
rm -f *.timestamp
|
|
|
|
clean: clean-timestamp
|
|
|
|
|
2009-12-07 22:04:52 +03:00
|
|
|
# will delete the target of a rule if commands exit with a nonzero exit status
|
|
|
|
.DELETE_ON_ERROR:
|
2012-05-22 15:41:27 +04:00
|
|
|
|
2020-03-06 20:04:56 +03:00
|
|
|
print-%:
|
|
|
|
@echo '$*=$($*)'
|