I understand deferred assignment (assigning things with = as opposed to :=), and I understand how to use #ifneq and similar commands for conditional assignment. How do I make a deferred conditional assignment?
Here is a psuedo-code example:
FOO = defined
BAR = $(defined(FOO) ? one : two)
test_1: $(BAR) #depends on one
FOO =
test_2: $(BAR) #depends on two
The main purpose of this is to configure my linker flags on the fly for static and dynamic builds. Building statically is more annoying that building dynamically because of circular dependencies (in addition to -fPIC removal and such). In this way, a couple variables change based on the definedness of STATIC (i.e. make STATIC=y). I could just define VAR and VAR_STATIC for each varable that needs variants, but I'd like to keep it has one global switch.
The kicker is that some submakes define rules that must be compiled dynamically in addition to rules that don't. Therefore, only a select few rules need to ignore the flag. This is why I would like to be able to toggle it on and off within the same Makefile.
Alternatively again, I could just reinclude the global Makefile when I need to toggle a flag, but that would not be preferred.
EDIT: From Come Raczy's solution, this is the specific syntax for my particular problem:
#Makefile
all: test_1 test_2
CFLAGS = -Wfatal-errors -std=c++11 -Wall -Werror -O3
CFLAGS += $(if $(DSYM),-g,)
test_1: DSYM:=y
test_2: DSYM:=
test_%: test.cpp
g++ $(CFLAGS) $< -o $#
clean:
rm -f test test_sym test_back
If I understand the question correctly, it is a combination of a conditional, deferred and per-target. Something like this:
BAR = $(if $(FOO), one, two)
all: test_1 test_2
FOO = defined
test_1: local_BAR:=$(BAR) #depends on one
FOO =
test_2: local_BAR:=$(BAR) #depends on two
test_%:
echo $*: $(local_BAR)
Related
Given the following GNU Makefile:
OBJS = a.o b.o
LIB = libX.a
$(LIB): $(OBJS)
$(AR) cr $# $^
$(LIB): CPPFLAGS = $(shell P)
When I build $(LIB), I can see that external program P is called twice, once each to build a.o and b.o (I have it just printing getpid() to stderr).
In my case, P will always produce the same result, so it's wasted cycles/time having P called for creation of every .o . LIB could be made of MANY .o's of course, and the problem worse.
Is there a way to get target-specific variables to only be evaluated once, i.e evaluated for the target $(LIB) and that VALUE, verbatim, be passed to the prerequisite recipes (.o from .c)? Or am I misunderstanding their usage (I suspect that I am!)
Tried various variable assignment syntaxes, e.g. = and :=, even ::=, all by trial and error. Read the manual over and over.
Is there a way to get target-specific variables to only be evaluated once, i.e evaluated for the target $(LIB) and that VALUE, verbatim, be passed to the prerequisite recipes (.o from .c)? Or am I misunderstanding their usage (I suspect that I am!)
The docs don't seem to specify the exact semantics of when and how target-specific variables are set for building the affected target's prerequisites. Your best bet for the behavior you want was to use simple variable assignment (:= or ::=), but you say that doesn't work. make seems to be behaving as if the variable assignment were included, separately, in the rule for each prerequisite, and that makes sense because in general, there is no guarantee that the prerequisites will all be built one after another or immediately before the main target, and where they aren't all built one right after another, the variable must resume its global value between.
Really, I'd like to encourage you to minimize your use of features specific to GNU make. Every one of them is a convenience, not a necessity, though occasionally, some of them are very convenient indeed. You might consider instead deploying Autoconf +/- Automake to (semi-)dynamically insert flags into your makefile.
But if you must use $(shell) in your makefile, and you want to be certain that the command is executed only once per make run, then your best bet is probably to run it outside any rule. If you don't want to modify the global CPPFLAGS then store the result instead in some other variable:
OBJS = a.o b.o
LIB = libX.a
X_CPPFLAGS := $(shell P)
$(LIB): $(OBJS)
$(AR) cr $# $^
$(LIB): CPPFLAGS = $(X_CPPFLAGS)
Situation
I am using a handwritten GNUmakefile in which CXXFLAGS, CPPFLAGS and LDFLAGS are appended to by the += assignment, as in:
CXXFLAGS += -std=c++11 $(MODENV) $(WARNINGS) $(OPTIMS)
CPPFLAGS += $(DMACROS) $(INCDIRS)
LDFLAGS += $(MODENV) $(LIBDIRS) $(EXTRA_LIBS)
Problem
When the user defines his own flags at the command-line, the appending in the Makefile will be ignored. This leaves the variables to exactly what the user set them. (And in my case, the build will fail.) The generic solution for this problem is to override the variables, as in:
override CXXFLAGS += -std=c++11 $(MODENV) $(WARNINGS) $(OPTIMS)
override CPPFLAGS += $(DMACROS) $(INCDIRS)
override LDFLAGS += $(MODENV) $(LIBDIRS) $(EXTRA_LIBS)
This way, the necessary content will be appended to the user's variable.
Questions
Is overriding variables considered bad practice?
Is setting the above flags inside the Makefile considered bad practice?
If "yes" to both questions above, then where do I put -std=c++11, if not in CXXFLAGS?
If a user overrides the variables, assume the user knows what they're doing. The system they're working on may have very different requirements and need to override the variables. Don't make the difficult impossible.
I'm not going to comment on good/bad practice, as it depends on the use case (who are the users of this makefile? Do they all work with you, so you could just tell them how it's meant to be used? Can you just document your conventions, in the makefile comments or a project README?)
But ...
where do I put -std=c++11, if not in CXXFLAGS?
If you have flags that are essential and must not be overridden by the user, you can find another way to put them in the compilation command.
For example:
CXX := g++ -std=c++11
Or:
foo.o: foo.cc
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -std=c++11 -o $# $^
Even better might be to use a variable so that it can still be set by the user (e.g. to use -std=c++14 instead) but isn't set by CXXFLAGS:
STD := -std=c++11
foo.o: foo.cc
$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(STD) -o $# $^
(Or just put the -std option before CXXFLAGS so that a different std option in CXXFLAGS will take precedence).
As the use cases for build management with make are so diverse, there simply is no ground to objectively judge this as "bad practice". If you are writing OSS for a multitude of platforms and for an unknown audience and timeframe, the POLA/POLS should be applied. That said, a user who is surprised to find more flags than the ones she gave on the command line is a rather unrealistic corner case, so -override has its place. In the end the values you add are absolutely necessary for the build, aren't they?
PS: the POLA should be applied to all engineering activities of course - its just that the definition of "surprise" shifts with the task in question.
I have some ancillary targets in a makefile that I want to restrict for internal or "private" use (only) inside the makefile. That is, I want to be able to specify these targets as dependencies from within the makefile, but I want to prevent the target from being specified as a build goal from the command line. Somewhat analogous to a private function from OOP: the target is harmful (or simply doesn't make sense) to build separately.
I wish there were a special-target .HIDDEN or .PRIVATE or something that did this, akin to what .PHONY does for non-file targets, but I don't think this exists. The private keyword is only for variables.
What is a good/general/elegant way to protect a target for internal/private use only?
The best workaround that I could come up with is to check $(MAKECMDGOALS) for "unacceptable" targets, then error-out if specified; this seems inelegant. I'm sure the makefile could be rewritten to avoid this situation -- perhaps a superior solution -- but that's not practical here.
Below the cut-line... here's a contrived example for illustration.
Though I'm looking for a general solution, one example of targets that are harmful as individual/primary goal is with inheriting of target-specific variable values:
override CFLAGS += -Wall
all : debug
%.o : %.c
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $# $<
debug : CFLAGS += -g3 -O0
release : CFLAGS += -O3
debug : CPPFLAGS += -DDEBUG
release : CPPFLAGS += -DRELEASE
debug release : foo.o bar.o main.o
$(CC) -o $# $^ $(LDFLAGS) $(LDLIBS)
clean:
-rm -f *.o debug release
.PHONY: all clean
Implicit rule duplicated (unnecessary) for illustration. With the goal of debug or release, foo.o and others will inherit respective CFLAGS and CPPFLAGS -- If one does make clean debug all objects will be consistent. But for example if someone builds foo.o separately, it will fail to inherit the appropriate flags; e.g., make clean foo.o debug you'll get foo.o built with default CFLAGS; then it doesn't need to be updated when building debug, so it will be linked with other objects with different optimizations or different macro settings. It will probably work in this case, but it's not what was intended. Marking foo.o, etc. as illegal goals would prevent this.
EDIT:
It's very clear that my example (above) was not a good choice for my more-general question: hiding targets was not the best way to fix an issue with my example. Here's a modified example that illustrates the modified question "How to enforce target-specific values?" -- it builds on commentary from #Michael, #Beta, #Ross below, and allows posing and answering this more limited scenario.
As described in previous responses below, it's a much better idea in this case to create objects that have different build flags in separate locations. e.g.,
bin_debug/%.o : %.c
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $# $<
bin_release/%.o : %.c
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $# $<
OBJS = foo.o bar.o main.o # or $(SRCS:.o=.c)
DEBUG_OBJS = $(addprefix bin_debug/,$OBJS)
RELEASE_OBJS = $(addprefix bin_release/,$OBJS)
debug : $(DEBUG_OBJS)
release : $(RELEASE_OBJS)
debug release :
$(CC) -o $# $^ $(LDFLAGS) $(LDLIBS)
Pattern rule duplicated because I think it has to be (multiple "pattern targets" (%) convince make all targets are built at once with one recipe; see SO questions this and this).
So now, add in target-specific flags:
debug : CPPFLAGS += -DDEBUG
release : CPPFLAGS += -DRELEASE
But this still suffers:
make bin_debug/foo.o
will not get the CPPFLAGS from debug. I've accepted #Michael's answer below as it got me thinking about the problem in a more helpful way, but also answered some of my own rhetorical questions below.
You kind of can define private targets by starting their name with two hyphens.
--private-target:
#echo private
public-target: --private-target
#echo public
You can call make public-target but make --private-target will complain about an unknown option:
$ make public-target
private
public
$ make --private-target
/Library/Developer/CommandLineTools/usr/bin/make: unrecognized option `--private-target'
This is not a feature of make, but takes advantage of the fact that command line options are passed with two hyphens and as a result make will complain about an unknown option. This also can be easily bypassed by signaling the end of options:
$ make -- --private-target
private
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
The problem you are trying to solve is legitimate but you are heading on the worse possible path to solve it.
Declaring private targets does not make any sense
When we write a Makefile, we are describing a compilation job in terms of targets, sources and recipes. The advancement of this job is described by the set of targets which are already built. Now you are accurately observing that the sequence
make clean
make foo.o
make debug
will produce objects whose format is inconsistent with foo.o thus leaving your build directory in an inconsistent state. But it is very wrong to deduce that the user should not be able to construct foo.o explicitly. Consider the following sequence:
make clean
# Wait for foo.o being compiles and
# interrupt the build job with a signal
make debug
Since make sees that foo.o it will resume its task where it was at and left foo.o untouched while compiling subsequent units with different flags, leaving the build directory the same inconsistent state as in the first scenario.
Hence, if we could implement private targets in Makefiles, this would be ineffective and could convey a false sense of security, which is even worse than insecurity by itself. Also the solution you imagined annihilates one of the most important advantages of using Makefiles over shell scripts: Make makes it easy to continue an interrupted task where it was at.
I documented some other aspects of using Makefiles in relation to the set of targets already built in my answer to the question “What is the purpose of linking object files separately in a Makefile?”.
Another solution to your problem
To address the issue of compilation flags inconsistency, we can arrange to store built targets into a special directory, depending on the compilation flags used. Implementing this would fix the issue without forcing us to resign upon the ease of resuming an interrupted compilation job.
Here is an implementation roadmap:
Identify build profiles, here you have release and build.
Choose which compilation to use for each build profile.
Choose in which directory to store built targets for each build profile.
Write your Makefile so that built targets are stored in the directories you choosed. Please refer Gnu make - how to get object files in separate subdirectory.
Note. In my opinion, the BSD variant of make has a much nicer support for writing targets in a special directory, see my answer to the question “How to write a Makefile using different directories for targets and sources”. Generally I prefer the BSD variant of make because its documentation is short and to the point and it enjoys a lot of useful advanced examples, since operating system build and ports build in the BSD world are orchestrated by this program.
One solution to the problem is to migrate the CPPFLAGS to the pattern rules (e.g., bin_debug/%.o: CPPFLAGS...) instead of the regular rule (debug: CPPFLAGS...), final result:
bin_debug/%.o : CPPFLAGS += -DDEBUG
bin_debug/%.o : %.c
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $# $<
bin_release/%.o : CPPFLAGS += -DRELEASE
bin_release/%.o : %.c
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $# $<
OBJS = foo.o bar.o main.o # or $(SRCS:.o=.c)
DEBUG_OBJS = $(addprefix bin_debug/,$OBJS)
RELEASE_OBJS = $(addprefix bin_release/,$OBJS)
debug : $(DEBUG_OBJS)
release : $(RELEASE_OBJS)
debug release :
$(CC) -o $# $^ $(LDFLAGS) $(LDLIBS)
so make bin_debug/foo.o will get CPPFLAGS including -DDEBUG.
Now, lets say you have >>2 rules: debug, release, config01, config02, config03, ... each with their own CPPFLAGS.
One way might be to continue reduplicating all of the pattern rules, but that gets annoying if anything has to change. Furthermore it's not really possible to use in a foreach. This seems handy:
debug : CPPFLAGS+=-DDEBUG
release : CPPFLAGS+=-DRELEASE
config01 : CPPFLAGS+=-DSOMETHING
config02 : CPPFLAGS+=-DSOMETHINGELSE
TARGETS = debug release config01 config02
OBJS = foo.o bar.o main.o # or $(SRCS:.o=.c)
define TARGET_template
bin_$(1)/%.o : %.c
$$(CC) $$(CFLAGS) $$(CPPFLAGS) -c -o $# $<
$(1): $(addprefix bin_$(1)/,$(OBJS))
# other TARGET-specific stuff here
endef
$(foreach tgt,$(TARGETS),$(eval $(call TARGET_template,$(tgt))))
But still doesn't fix the situation of make bin_debug/foo.o -- still doesn't get CPPFLAGS.
So, instead of making target-specific variable-value like debug: CPPFLAGS+=... you could have a variable that is specific to the target, like CPPFLAGS_debug, then add to each rule:
CPPFLAGS_debug = -DDEBUG
CPPFLAGS_release = -DRELEASE
CPPFLAGS_config01 = -DSOMETHING
CPPFLAGS_config02 = -DSOMETHINGELSE
TARGETS = debug release config01 config02
OBJS = foo.o bar.o main.o # or $(SRCS:.o=.c)
define TARGET_template
bin_$(1)/%.o : CPPFLAGS+=$$(CPPFLAGS_$(1))
bin_$(1)/%.o : %.c
$$(CC) $$(CFLAGS) $$(CPPFLAGS) -c -o $$# $$<
$(1): $(addprefix bin_$(1)/,$(OBJS))
# other TARGET-specific stuff here
endef
$(foreach tgt,$(TARGETS),$(eval $(call TARGET_template,$(tgt))))
Beware; above may need more $$(...)s, untested.
Problems? Better way?
Thinking about this and tried the following:
TEST := $(shell echo $$RANDOM)
test : $(TEST)
$(TEST):
<tab>#echo tada $(TEST)
then doing a make test on command line seems to work and I think it would be difficult to get the result without using the test target. Maybe this path can help?
I don't think there's any "elegant" way to have targets somehow made private. I think the only solution that could be called elegant would be to rewrite your makefile so that it doesn't matter what target users invoke, as Beta suggests. It would also have the advantage of making your makefile more maintainable and easier to understand.
A not so elegant but fairly simple way to make targets "private" would be to rename the makefile to something other than one of the default names. Then put a new makefile in it's place that invokes the "private" makefile to do it's work. Something like:
.SUFFIXES:
PUBLIC_TARGETS = all debug release clean
REAL_MAKEFILE = private.mak
define invoke_make
$(1): $(REAL_MAKEFILE)
$(MAKE) -f $(REAL_MAKEFILE) $(1)
endef
$(foreach target, $(PUBLIC_TARGETS), $(eval $(call invoke_make,$(target))))
.PHONY: $(PUBLIC_TARGETS)
Obviously this doesn't prevent a determined user from invoking "private" targets, but hopefully it makes it clear that they shouldn't be doing this. That's all making things private in object-oriented languages does anyways. It's always possible for a sufficiently determined user to bypass it.
Even if previous speakers called this a bad idea, I was very interested in the concept of having a custom special target like .PRIVATE to more or less protect some targets from beeing called straigt.
And for everyone interested in it... this is what I came up with:
ifeq ($(strip $(filter .PRIVATE,$(MAKECMDGOALS))),)
__PRIVATEGOALS = $(shell make -f $(firstword $(MAKEFILE_LIST)) -n .PRIVATE | tail -n 1)
$(foreach __privgoal,$(__PRIVATEGOALS),$(eval __PRIVATECMDGOALS += $(filter $(__privgoal),$(MAKECMDGOALS))))
endif
ifneq ($(strip $(__PRIVATECMDGOALS)),)
$(error tried to call *private* goal(s) $(strip $(__PRIVATECMDGOALS)))
endif
.PHONY: .PRIVATE
.SILENT: .PRIVATE
.PRIVATE:
##
$^
Put it at the top of your makefile, or at least in front of the first target declared as private. You could as well put it into a separate file, like private.mk and include it in your main makefile.
You should be able to use the .PRIVATE target in the same way as you use the .SILENT or the .PHONY targets. An error is triggered in case a "private" target is called and make stops.
I was a little confused with the responses to Quick way to override -Werror flag?
So I ask my specific question here.
I have multiple Makefiles working together and CFLAGS has been set along the way to (-Werror -Wall .. and many others)
But in one of the Makefiles, I wish that the errors not be treated as warnings and so I would like to remove -Werror flag.
What would be the best way to achieve this, so that only for this Makefile, -Werror flag is removed and for the others normal execution takes place?
Thanks,
Sunny
The right way to do this is with the filter-out function.
Put
CFLAGS := $(filter-out -Werror,$(CFLAGS))
in the Makefile where you want to override this, and the -Werror part of CFLAGS will be removed in that Makefile.
You can even use this to override flags for a single target by using target-specific variable values:
CFLAGS = -Werror
all: foo bar
foo:
echo cc $(CFLAGS) -o $#
bar: CFLAGS := $(filter-out -Werror,$(CFLAGS))
bar:
echo cc $(CFLAGS) -o $#
foo will be built with the default CFLAGS containing -Werror, but bar will be built without.
This is a general-purpose solution that works for all arguments to all programs, rather than requiring each program to supply a --no-foo for every --foo option.
Because it can’t be done from Make command-line, it doesn’t directly answer the question you linked to. But overriding Make variables from the command-line to force stuff to build is a pretty good way to make your unbuildable code even less maintainable!
Simpler way
It looks like you can invoke
gcc -c ... -Werror ... -Wno-error ...
without having GCC complain (GCC 4.7.1). So, you can add -Wno-error to the CFLAGS set up elsewhere in the one makefile where you need it. If you're using GNU make, in the one makefile, you can add:
CFLAGS += -Wno-error
possibly for just the single target that needs it.
Harder way
Otherwise, you need a system for building CFLAGS from components. What I have in the makefile I use for testing answers to questions on SO is:
WFLAG1 = -Wall
WFLAG2 = -Wextra
WFLAG3 = -Wmissing-prototypes
WFLAG4 = -Wstrict-prototypes
WFLAG5 = -Wold-style-definition
WFLAG6 =
WFLAGS = ${WFLAG1} ${WFLAG2} ${WFLAG3} ${WFLAG4} ${WFLAG5} ${WFLAG6}
SFLAGS = -std=c99
GFLAGS = -g
OFLAGS = -O3
UFLAGS =
IFLAG1 = -I${HOME}/inc
IFLAGS = # ${IFLAG1}
CFLAGS = ${OFLAGS} ${GFLAGS} ${IFLAGS} ${SFLAGS} ${WFLAGS} ${UFLAGS}
The main point is that each flag is independently adjustable; I can control the warning flags by setting any of ${WFLAG1} to ${WFLAG6}, or by setting ${WFLAGS} wholesale on the command line, or (indeed) by setting ${CFLAGS}. But because each is individually adjustable, and can tune the warnings relatively easily (the main hassle being determining which WFLAGn needs clobbering).
The UFLAGS is 'user flags' and is only set on the command line; I can add more flags to my command line by setting it.
This way is 'harder' because it requires you to modify the central part of your makefile system where you set CFLAGS. It is also less likely to be understood by your colleagues at first sight.
You can see an example of variable overriding in Git Makefile with CFLAGS which now can be tweaked when invoking Make while using DEVELOPER=YesPlease, with Git 2.22 (Q2 2019)
DEVELOPER (in Git Makefile) is a variable to group more compiler warning.
See commit 6d5d4b4, commit 71a7894, commit 8fb2a23, commit 65260a4, commit 9559f8f, commit 4f14a8c (22 Feb 2019) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 3cef676, 20 Mar 2019)
Makefile: allow for combining DEVELOPER=1 and CFLAGS="..."
Ever since the DEVELOPER=1 facility introduced there's been no way to have custom CFLAGS (e.g. CFLAGS="-O0 -g -ggdb3") while still benefiting from the set of warnings and assertions DEVELOPER=1 enables.
This is because the semantics of variables in the Makefile are such
that the user setting CFLAGS overrides anything we set, including what
we're doing in config.mak.dev.
So let's introduce a "DEVELOPER_CFLAGS" variable in config.mak.dev and
add it to ALL_CFLAGS. Before this the ALL_CFLAGS variable
would (basically, there's some nuance we won't go into) be set to:
$(CPPFLAGS) [$(CFLAGS) *or* $(CFLAGS) in config.mak.dev] $(BASIC_CFLAGS) $(EXTRA_CPPFLAGS)
But will now be:
$(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(BASIC_CFLAGS) $(EXTRA_CPPFLAGS)
The reason for putting DEVELOPER_CFLAGS first is to allow for
selectively overriding something DEVELOPER=1 brings in.
On both GCC and Clang later settings override earlier ones.
E.g. "-Wextra -Wno-extra" will enable no "extra" warnings, but not if those two
arguments are reversed.
Examples of things that weren't possible before, but are now:
# Use -O0 instead of -O2 for less painful debuggng
DEVELOPER=1 CFLAGS="-O0 -g"
# DEVELOPER=1 plus -Wextra, but disable some of the warnings
DEVELOPER=1 DEVOPTS="no-error extra-all" CFLAGS="-O0 -g -Wno-unused-parameter"
The reason for the patches leading up to this one re-arranged the
various *FLAGS assignments and includes is just for readability.
The Makefile supports assignments out of order, e.g.:
$ cat Makefile
X = $(A) $(B) $(C)
A = A
B = B
include c.mak
all:
#echo $(X)
$ cat c.mak
C=C
$ make
A B C
I have a Makefile which includes makefiles from sub-directories.
However, what I want is to include these "sub"-makefiles on base of a selected target.
Background is, that the sub-makefiles define different object files and depending on these object files the target executable should be created.
Assuming sub-makefile1 sets the variable
OBJECTS := foo.o foo1.o
sub-makefile2 sets
OBJECTS := bar.o bar1.o
And the generic rule would be:
lib/%.so: $(OBJECTS)
link $^ -o $#
The targets are (for example):
foo: lib/foo.so
bar: lib/bar.so
whereas target foo should include the foo makefile, target bar the bar-makefile.
Any idea how to handle this situation?
Thanks,
Christian
Beta has mentioned the $(MAKECMDGOALS), but not described it:
ifeq ($(MAKECMDGOALS),foo)
include sub-makefile1
endif
ifeq ($(MAKECMDGOALS),bar)
include sub-makefile2
endif
# Rest of Makefile follows...
This isn't such a great idea, as it will only work when make is called interactively. You can hack around this by making rules for foo and bar that recursively invoke make:
ifeq ($(MAKECMDGOALS),foo)
include sub-makefile1
foo: # ...
# Normal commands to build foo
else
foo:
$(MAKE) $<
endif
ifeq ($(MAKECMDGOALS),bar)
include sub-makefile2
bar: # ...
# Normal commands to build bar
else
bar:
$(MAKE) $<
endif
The specific thing you're asking for -- conditional inclusion -- is difficult in Make. It can be done, but it's not elegant.
There are several ways to get the effect you want. You could use a conditional on MAKECMDGOALS. You could could have your makefile invoke a second makefile, and pass it the name of the subdirectory to use. But (without knowing more about the situation) I think this way is the tidiest:
include sub-makefile1
FOO_OBJECTS := $(OBJECTS)
include sub-makefile2
BAR_OBJECTS := $(OBJECTS)
lib/%.so:
link $^ -o $#
lib/foo.so: $(FOO_OBJECTS)
lib/bar.so: $(BAR_OBJECTS)
foo bar : % : lib/%.so
(You could be clever with variable names like foo_OBJECTS to save a line or two, but I advise against that.)