qemu-e2k/rules.mak

159 lines
5.1 KiB
Makefile
Raw Normal View History

# These are used when we want to do substitutions without confusing Make
NULL :=
SPACE := $(NULL) #
COMMA := ,
# 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
%/trace-events:
%.hx:
%.py:
%.objs:
%.d:
%.h:
%.c:
%.cc:
%.cpp:
%.m:
%.mak:
# Flags for dependency generation
QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(@D)/$(*F).d
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 17:14:10 +01: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.
QEMU_LOCAL_INCLUDES = -iquote $(BUILD_DIR) -iquote $(BUILD_DIR)/$(@D) -iquote $(@D)
WL := -Wl,
ifdef CONFIG_DARWIN
whole-archive = $(WL)-force_load,$1
else
whole-archive = $(WL)--whole-archive $1 $(WL)--no-whole-archive
endif
extract-libs = $(strip $(foreach o,$1,$($o-libs)))
%.o: %.c
@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 17:14:10 +01:00
$(call quiet-command,$(CC) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
$(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) \
-c -o $@ $<,"CC","$(TARGET_DIR)$@")
# 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))
LINK = $(call quiet-command, $(LINKPROG) $(CFLAGS) $(QEMU_LDFLAGS) -o $@ \
$(filter-out %.a %.fa,$1) \
$(foreach l,$(filter %.fa,$1),$(call whole-archive,$l)) \
$(filter %.a,$1) \
$(call extract-libs,$1) $(LIBS),"LINK","$(TARGET_DIR)$@")
%.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 17:14:10 +01:00
$(call quiet-command,$(CCAS) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
$(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) \
-c -o $@ $<,"CCAS","$(TARGET_DIR)$@")
%.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 17:14:10 +01:00
$(call quiet-command,$(CXX) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
$(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 17:14:10 +01:00
-c -o $@ $<,"CXX","$(TARGET_DIR)$@")
%.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 17:14:10 +01:00
$(call quiet-command,$(CXX) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
$(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 17:14:10 +01:00
-c -o $@ $<,"CXX","$(TARGET_DIR)$@")
%.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 17:14:10 +01:00
$(call quiet-command,$(OBJCC) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
$(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) \
-c -o $@ $<,"OBJC","$(TARGET_DIR)$@")
%.o: %.dtrace
rules.mak: quiet-command: Split command name and args to print The quiet-command make rule currently takes two arguments: the command and arguments to run, and a string to print if the V flag is not set (ie we are not being verbose). By convention, the string printed is of the form " NAME some args". Unfortunately to get nicely lined up output all the strings have to agree about what column the arguments should start in, which means that if we add a new quiet-command usage which wants a slightly longer CMD name then we either put up with misalignment or change every quiet-command string. Split the quiet-mode string into two, the "NAME" and the "same args" part, and use printf(1) to format the string automatically. This means we only need to change one place if we want to support a longer maximum name. In particular, we can now print 7-character names lined up properly (they are needed for the OSX "SETTOOL" invocation). Change all the uses of quiet-command to the new syntax. (Any which are missed or inadvertently reintroduced via later merges will result in slightly misformatted quiet output rather than disaster.) A few places in the pc-bios/ makefiles are updated to use "BUILD", "SIGN" and "STRIP" rather than "Building", "Signing" and "Stripping" for consistency and to keep them below 7 characters. Module .mo links now print "LD" rather than the nonstandard "LD -r". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1475598441-27908-1-git-send-email-peter.maydell@linaro.org
2016-10-04 18:27:21 +02:00
$(call quiet-command,dtrace -o $@ -G -s $<,"GEN","$(TARGET_DIR)$@")
.PHONY: modules
modules:
%$(EXESUF): %.o
$(call LINK,$(filter %.o %.a %.fa, $^))
%.a:
rules.mak: quiet-command: Split command name and args to print The quiet-command make rule currently takes two arguments: the command and arguments to run, and a string to print if the V flag is not set (ie we are not being verbose). By convention, the string printed is of the form " NAME some args". Unfortunately to get nicely lined up output all the strings have to agree about what column the arguments should start in, which means that if we add a new quiet-command usage which wants a slightly longer CMD name then we either put up with misalignment or change every quiet-command string. Split the quiet-mode string into two, the "NAME" and the "same args" part, and use printf(1) to format the string automatically. This means we only need to change one place if we want to support a longer maximum name. In particular, we can now print 7-character names lined up properly (they are needed for the OSX "SETTOOL" invocation). Change all the uses of quiet-command to the new syntax. (Any which are missed or inadvertently reintroduced via later merges will result in slightly misformatted quiet output rather than disaster.) A few places in the pc-bios/ makefiles are updated to use "BUILD", "SIGN" and "STRIP" rather than "Building", "Signing" and "Stripping" for consistency and to keep them below 7 characters. Module .mo links now print "LD" rather than the nonstandard "LD -r". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1475598441-27908-1-git-send-email-peter.maydell@linaro.org
2016-10-04 18:27:21 +02:00
$(call quiet-command,rm -f $@ && $(AR) rcs $@ $^,"AR","$(TARGET_DIR)$@")
rules.mak: quiet-command: Split command name and args to print The quiet-command make rule currently takes two arguments: the command and arguments to run, and a string to print if the V flag is not set (ie we are not being verbose). By convention, the string printed is of the form " NAME some args". Unfortunately to get nicely lined up output all the strings have to agree about what column the arguments should start in, which means that if we add a new quiet-command usage which wants a slightly longer CMD name then we either put up with misalignment or change every quiet-command string. Split the quiet-mode string into two, the "NAME" and the "same args" part, and use printf(1) to format the string automatically. This means we only need to change one place if we want to support a longer maximum name. In particular, we can now print 7-character names lined up properly (they are needed for the OSX "SETTOOL" invocation). Change all the uses of quiet-command to the new syntax. (Any which are missed or inadvertently reintroduced via later merges will result in slightly misformatted quiet output rather than disaster.) A few places in the pc-bios/ makefiles are updated to use "BUILD", "SIGN" and "STRIP" rather than "Building", "Signing" and "Stripping" for consistency and to keep them below 7 characters. Module .mo links now print "LD" rather than the nonstandard "LD -r". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1475598441-27908-1-git-send-email-peter.maydell@linaro.org
2016-10-04 18:27:21 +02: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.
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)
# cc-option
# Usage: CFLAGS+=$(call cc-option, -falign-functions=0, -malign-functions=0)
cc-option = $(if $(shell $(CC) $1 $2 -S -o /dev/null -xc /dev/null \
>/dev/null 2>&1 && echo OK), $2, $3)
cc-c-option = $(if $(shell $(CC) $1 $2 -c -o /dev/null -xc /dev/null \
>/dev/null 2>&1 && echo OK), $2, $3)
VPATH_SUFFIXES = %.c %.h %.S %.cc %.cpp %.m %.mak %.texi %.sh %.rc Kconfig% %.json.in
set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath $(PATTERN) $1)))
# install-prog list, dir
define install-prog
$(INSTALL_DIR) "$2"
$(INSTALL_PROG) $1 "$2"
$(if $(STRIP),$(STRIP) $(foreach T,$1,"$2/$(notdir $T)"),)
endef
# 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)
# 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)
.PHONY: clean-timestamp
clean-timestamp:
rm -f *.timestamp
clean: clean-timestamp
# will delete the target of a rule if commands exit with a nonzero exit status
.DELETE_ON_ERROR:
print-%:
@echo '$*=$($*)'