Chapter 4: Writing Rules
If .DELETE_ON_ERROR is mentioned as a target anywhere in the makeﬁle, then
make will delete the target of a rule if it has changed and its recipe exits with
anonzero exit status, just as it does when it receives a signal. SeeSection5.5
[Errors in Recipes], page 49.
If you specify prerequisites for .IGNORE,then make willignoreerrors in execution
of the recipe for those particular ﬁles. The recipe for .IGNORE (if any) is ignored.
If mentioned as a target with no prerequisites, .IGNORE says to ignore errors in
execution of recipes for all ﬁles. This usage of ‘.IGNORE’ is supported only for
historical compatibility. Since this aﬀects every recipe in the makeﬁle, it is not
very useful; we recommend you use the more selective ways to ignore errors in
speciﬁc recipes. SeeSection5.5[ErrorsinRecipes],page49.
If you specify prerequisites for .LOW_RESOLUTION_TIME, make assumes that
these ﬁles are created by commands that generate low resolution time stamps.
The recipe for the .LOW_RESOLUTION_TIME target are ignored.
The high resolution ﬁle time stamps of many modern ﬁle systems lessen the
chance of make incorrectly concluding that a ﬁle is up to date. Unfortunately,
some hosts do not provide a way to set a high resolution ﬁle time stamp, so
commands like ‘cp -p’ that explicitly set a ﬁle’s time stamp must discard its
sub-second part. If a ﬁle is created by such a command, you should list it
as a prerequisite of .LOW_RESOLUTION_TIME so that make does not mistakenly
conclude that the ﬁle is out of date. For example:
cp -p src dst
Since ‘cp -p’ discards the sub-second part of src’s time stamp, dst is typically
slightly older than src even when it is up to date. The .LOW_RESOLUTION_TIME
line causes make to consider dst to be up to date if its time stamp is at the
start of the same second that src’s time stamp is in.
Due to a limitation of the archive format, archive member time stamps are
always low resolution. You need not list archive members as prerequisites of
.LOW_RESOLUTION_TIME, as make does this automatically.
If you specify prerequisites for .SILENT, then make will not print the recipe used
to remake those particular ﬁles before executing them. The recipe for .SILENT
If mentioned as a target with no prerequisites, .SILENT says not to print any
recipes before executing them. This usage of ‘.SILENT’ is supported only for
historical compatibility. We recommend you use the more selective ways to
silence speciﬁc recipes. SeeSection5.2[RecipeEchoing],page43. If you want
to silence all recipes for a particular run of make, use the ‘-s’ or ‘--silent’
Simply by being mentioned as a target, this tells make to export all variables
to child processes by default. SeeSection5.7.2[CommunicatingVariablestoa
Sub-make], page 52.
If .NOTPARALLEL is mentioned as a target, then this invocation of make will
be run serially, even if the ‘-j’ option is given. Any recursively invoked make
command will still run recipes in parallel (unless its makeﬁle also contains this
target). Any prerequisites on this target are ignored.
If .ONESHELL is mentioned as a target, then when a target is built all lines of
the recipe will be given to a single invocation of the shell rather than each line
being invoked separately (seeSection5.3[RecipeExecution],page44).
If .POSIX is mentioned as a target, then the makeﬁle will be parsed and run
in POSIX-conforming mode. This does not mean that only POSIX-conforming
makeﬁles will be accepted: all advanced GNU make features are still available.
Rather, this target causes make to behave as required by POSIX in those areas
where make’s default behavior diﬀers.
In particular, if this target is mentioned then recipes will be invoked as if the
shell had been passed the -e ﬂag: the ﬁrst failing command in a recipe will
cause the recipe to fail immediately.
Any deﬁned implicit rule suﬃx also counts as a special target if it appears as a target,
and so does the concatenation of two suﬃxes, such as ‘.c.o’. These targets are suﬃx rules,
an obsolete way of deﬁning implicit rules (but a way still widely used). In principle, any
target name could be special in this way if you break it in two and add both pieces to the
suﬃx list. In practice, suﬃxes normally begin with ‘.’, so these special target names also
begin with ‘.’. SeeSection10.7[Old-FashionedSuﬃxRules],page125.
4.9 Multiple Targets in a Rule
Arule with multiple targets is equivalent to writing many rules, each with one target, and
all identical aside from that. The same recipe applies to all the targets, but its eﬀect may
vary because you can substitute the actual target name into the recipe using ‘$@’. The rule
contributes the same prerequisites to all the targets also.
This is useful in two cases.
You want just prerequisites, no recipe. For example:
kbd.o command.o files.o: command.h
gives an additional prerequisite to each of the three object ﬁles mentioned.
Similar recipes work for all the targets. The recipes do not need to be absolutely
identical, since the automatic variable ‘$@’ can be used to substitute the particular
target to be remade into the commands (see Section 10.5.3 [Automatic Variables],
page 120). Forexample:
Chapter 4: Writing Rules
bigoutput littleoutput : text.g
generate text.g -$(subst output,,$@) > $@
is equivalent to
bigoutput : text.g
generate text.g -big > bigoutput
littleoutput : text.g
generate text.g -little > littleoutput
Here we assume the hypothetical program generate makes two types of output, one if
given ‘-big’ and one if given ‘-little’. SeeSection8.2[FunctionsforStringSubsti-
tution and Analysis], page 84,foranexplanationofthesubstfunction.
Suppose you would like to vary the prerequisites according to the target, much as the
variable ‘$@’ allows you to vary the recipe. You cannot do this with multiple targets in an
ordinary rule, but you can do it with a static pattern rule. SeeSection4.11[StaticPattern
Rules], page 36.
4.10 Multiple Rules for One Target
One ﬁle can be the target of several rules. All the prerequisites mentioned in all the rules
are merged into one list of prerequisites for the target. If the target is older than any
prerequisite from any rule, the recipe is executed.
There can only be one recipe to be executed for a ﬁle. If more than one rule gives a
recipe for the same ﬁle, make uses the last one given and prints an error message. (As a
special case, if the ﬁle’s name begins with a dot, no error message is printed. This odd
behavior is only for compatibility with other implementations of make.. . you should avoid
using it). Occasionally it is useful to have the same target invoke multiple recipes which are
deﬁned in diﬀerent parts of your makeﬁle; you can use double-colon rules (seeSection4.12
[Double-Colon], page 38)forthis.
Anextra rule withjust prerequisites can be usedto give a few extra prerequisites to many
ﬁles at once. For example, makeﬁles often have a variable, such as objects, containing a
list of all the compiler output ﬁles in the system being made. An easy way to say that all
of them must be recompiled if config.h changes is to write the following:
objects = foo.o bar.o
foo.o : defs.h
bar.o : defs.h test.h
$(objects) : config.h
This could be inserted or taken out without changing the rules that really specify how to
make the object ﬁles, making it a convenient form to use if you wish to add the additional
Another wrinkle is that the additional prerequisites could be speciﬁed with a variable
that you set with a command line argument to make (seeSection9.5[OverridingVariables],
page 103). Forexample,
$(objects) : $(extradeps)
means that the command ‘make extradeps=foo.h’ will consider foo.h as a prerequisite of
each object ﬁle, but plain ‘make’ will not.
If none of the explicit rules for a target has a recipe, then make searches for an applicable
implicit rule to ﬁnd one seeChapter10[UsingImplicitRules],page111).
4.11 Static Pattern Rules
Static pattern rules are rules which specify multiple targets and construct the prerequisite
names for each target based on the target name. They are more general than ordinary rules
with multiple targets because the targets do not have to have identical prerequisites. Their
prerequisites must be analogous, but not necessarily identical.
4.11.1 Syntax of Static Pattern Rules
Here is the syntax of a static pattern rule:
targets ...: target-pattern: prereq-patterns ...
The targets list speciﬁes the targets that the rule applies to. The targets can contain
wildcard characters, just like the targets of ordinary rules (seeSection4.3[UsingWildcard
Characters in File Names], page 23).
The target-pattern and prereq-patterns say how to compute the prerequisites of each
target. Each target is matched against the target-pattern to extract a part of the target
name, called the stem. This stem is substituted into each of the prereq-patterns to make
the prerequisite names (one from each prereq-pattern).
Each pattern normally contains the character ‘%’ just once. When the target-pattern
matches a target, the ‘%’ can match any part of the target name; this part is called the
stem. The rest of the pattern must match exactly. For example, the target foo.o matches
the pattern ‘%.o’, with ‘foo’ as the stem. The targets foo.c and foo.out do not match
The prerequisite names for each target are made by substituting the stem for the ‘%’ in
each prerequisite pattern. For example, if one prerequisite pattern is %.c, then substitution
of the stem ‘foo’ gives the prerequisite name foo.c. It is legitimate to write a prerequisite
pattern that does not contain ‘%’; then this prerequisite is the same for all targets.
‘%’ characters in pattern rules can be quoted with preceding backslashes (‘\’). Back-
slashes that would otherwise quote ‘%’ characters can be quoted with more backslashes.
Backslashes that quote ‘%’ characters or other backslashes are removed from the pattern
before it is compared to ﬁle names or has a stem substituted into it. Backslashes that
are not in danger of quoting ‘%’ characters go unmolested. For example, the pattern
the\%weird\\%pattern\\ has ‘the%weird\’ preceding the operative ‘%’ character, and
‘pattern\\’ following it. The ﬁnal two backslashes are left alone because they cannot
aﬀect any ‘%’ character.
Here is an example, which compiles each of foo.o and bar.o from the corresponding .c
Chapter 4: Writing Rules
objects = foo.o bar.o
$(objects): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@
Here ‘$<’ is the automatic variable that holds the name of the prerequisite and ‘$@’ is
the automatic variable that holds the name of the target; see Section10.5.3[Automatic
Variables], page 120.
Each target speciﬁed must match the target pattern; a warning is issued for each target
that does not. If you have a list of ﬁles, only some of which will match the pattern, you can
use the filter function to remove non-matching ﬁle names (seeSection8.2[Functionsfor
String Substitution and Analysis], page 84):
files = foo.elc bar.o lose.o
$(filter %.o,$(files)): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@
$(filter %.elc,$(files)): %.elc: %.el
emacs -f batch-byte-compile $<
In this example the result of ‘$(filter %.o,$(files))’is bar.o lose.o,andthe ﬁrst static
pattern rule causes each of these object ﬁles to be updated by compiling the corresponding
Csource ﬁle. The result of ‘$(filter %.elc,$(files))’ is foo.elc, so that ﬁle is made
Another example shows how to use $* in static pattern rules:
bigoutput littleoutput : %output : text.g
generate text.g -$* > $@
When the generate command is run, $* will expand to the stem, either ‘big’ or ‘little’.
4.11.2 Static Pattern Rules versus Implicit Rules
Astatic pattern rule has much in common with an implicit rule deﬁned as a pattern rule
(seeSection10.5[DeﬁningandRedeﬁningPatternRules],page118). Both have a pattern
for the target and patterns for constructing the names of prerequisites. The diﬀerence is in
how make decides when the rule applies.
An implicit rule can apply to any target that matches its pattern, but it does apply
only when the target has no recipe otherwise speciﬁed, and only when the prerequisites can
be found. If more than one implicit rule appears applicable, only one applies; the choice
depends on the order of rules.
By contrast, a static pattern rule applies to the precise list of targets that you specify
in the rule. It cannot apply to any other target and it invariably does apply to each of the
targets speciﬁed. If two conﬂicting rules apply, and both have recipes, that’s an error.
The static pattern rule can be better than an implicit rule for these reasons:
You may wish to override the usual implicit rule for a few ﬁles whose names cannot be
categorized syntactically but can be given in an explicit list.
If you cannot be sure of the precise contents of the directories you are using, you may
not be sure which other irrelevant ﬁles might lead make to use the wrong implicit rule.
The choice might depend on the order in which the implicit rule search is done. With
static pattern rules, there is no uncertainty: each rule applies to precisely the targets
4.12 Double-Colon Rules
Double-colon rules are explicit rules written with ‘::’ instead of ‘:’ after the target names.
They are handled diﬀerently from ordinary rules when the same target appears in more
than one rule. Pattern rules with double-colons have an entirely diﬀerent meaning (see
Section 10.5.5 [Match-Anything Rules], page 123).
When a target appears inmultiple rules, allthe rules must be the same type: all ordinary,
or all double-colon. If they are double-colon, each of them is independent of the others.
Each double-colon rule’s recipe is executed if the target is older than any prerequisites of
that rule. If there are no prerequisites for that rule, its recipe is always executed (even if
the target already exists). This can result in executing none, any, or all of the double-colon
Double-colonrules withthe same target are in fact completely separate from one another.
Each double-colon rule is processed individually, just as rules with diﬀerent targets are
The double-colon rules for a target are executed in the order they appear in the makeﬁle.
However, the cases where double-colon rules really make sense are those where the order of
executing the recipes would not matter.
Double-colon rules are somewhat obscure and not often very useful; they provide a
mechanism for cases in which the method used to update a target diﬀers depending on
which prerequisite ﬁles caused the update, and such cases are rare.
Each double-colon rule should specify a recipe; if it does not, an implicit rule will be
used if one applies. SeeChapter10[UsingImplicitRules],page111.
4.13 Generating Prerequisites Automatically
In the makeﬁle for a program, many of the rules you need to write often say only that
some object ﬁle depends on some header ﬁle. For example, if main.c uses defs.h via an
#include, you would write:
You need this rule so that make knows that it must remake main.o whenever defs.h
changes. You can see that for a large program you would have to write dozens of such rules
in your makeﬁle. And, you must always be very careful to update the makeﬁle every time
you add or remove an #include.
To avoid this hassle, most modern C compilers can write these rules for you, by looking
at the #include lines in the source ﬁles. Usually this is done with the ‘-M’ option to the
compiler. For example, the command:
cc -M main.c
generates the output:
Chapter 4: Writing Rules
main.o : main.c defs.h
Thus you no longer have to write all those rules yourself. The compiler will do it for you.
Note that such a rule constitutes mentioning main.o in a makeﬁle, so it can never be
considered an intermediate ﬁle by implicit rule search. This means that make won’t ever
remove the ﬁle after using it; seeSection10.4[ChainsofImplicitRules],page117.
With old make programs, it was traditional practice to use this compiler feature to
generate prerequisites on demand with a command like ‘make depend’. That command
would create a ﬁle depend containing all the automatically-generated prerequisites; then
the makeﬁle could use include to read them in (seeSection3.3[Include],page13).
In GNU make, the feature of remaking makeﬁles makes this practice obsolete—you need
never tell make explicitly to regenerate the prerequisites, because it always regenerates any
makeﬁle that is out of date. SeeSection3.5[RemakingMakeﬁles],page14.
The practice we recommend for automatic prerequisite generation is to have one makeﬁle
corresponding to each source ﬁle. For each source ﬁle name.c there is a makeﬁle name.d
which lists what ﬁles the object ﬁle name.o depends on. That way only the source ﬁles that
have changed need to be rescanned to produce the new prerequisites.
Here is the pattern rule to generate a ﬁle of prerequisites (i.e., a makeﬁle) called name.d
from a C source ﬁle called name.c:
@set -e; rm -f $@; \
$(CC) -M $(CPPFLAGS) $< > $@.$$$$; \
sed ’s,\($*\)\.o[ :]*,\1.o $@ : ,g’ < $@.$$$$ > $@; \
rm -f $@.$$$$
SeeSection10.5[PatternRules],page118, for information on deﬁning pattern rules. The
‘-e’ ﬂag to the shell causes it to exit immediately if the $(CC) command (or any other
command) fails (exits with a nonzero status).
With the GNU C compiler, you may wish to use the ‘-MM’ ﬂag instead of ‘-M’. This omits
prerequisites on system header ﬁles. SeeSection“OptionsControllingthePreprocessor”in
Using GNU CC,fordetails.
The purpose of the sed command is to translate (for example):
main.o : main.c defs.h
main.o main.d : main.c defs.h
This makes each ‘.d’ ﬁle depend on all the source and header ﬁles that the corresponding
‘.o’ ﬁle depends on. make then knows it must regenerate the prerequisites whenever any of
the source or header ﬁles changes.
Once you’ve deﬁned the rule to remake the ‘.d’ ﬁles, you then use the include directive
to read them all in. SeeSection3.3[Include],page13. For example:
sources = foo.c bar.c
(This example uses a substitutionvariable reference to translate the list ofsourceﬁles ‘foo.c
bar.c’ into a list of prerequisite makeﬁles, ‘foo.d bar.d’. SeeSection6.3.1[Substitution
Refs], page 62, for r full l information on substitution references.) ) Since e the e ‘.d’ ’ ﬁles are
makeﬁles like any others, make will remake them as necessary with no further work from
Note that the ‘.d’ ﬁles containtarget deﬁnitions; youshouldbe sure to place the include
directive after the ﬁrst, default goal in your makeﬁles or run the risk of having a random
object ﬁle become the default goal. SeeSection2.3[HowMakeWorks],page5.
Documents you may be interested
Documents you may be interested