[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.12.1 Syntax of Static Pattern Rules | The syntax of static pattern rules. | |
4.12.2 Static Pattern Rules versus Implicit Rules | When are they better than implicit rules? |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here is the syntax of a static pattern rule:
targets …: target-pattern: prereq-patterns … recipe … |
The targets list specifies the targets that the rule applies to. The targets can contain wildcard characters, just like the targets of ordinary rules (see section Using Wildcard Characters in File Names).
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 that pattern.
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 (‘\’). Backslashes 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 file 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 final two backslashes are left alone because they cannot affect any ‘%’ character.
Here is an example, which compiles each of ‘foo.o’ and ‘bar.o’ from the corresponding ‘.c’ file:
objects = foo.o bar.o all: $(objects) $(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 Automatic Variables.
Each target specified must match the target pattern; a warning is issued
for each target that does not. If you have a list of files, only some of
which will match the pattern, you can use the filter
function to
remove nonmatching file names (see section Functions for String Substitution and Analysis):
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’, and the first static pattern rule causes each of these object files to be updated by compiling the corresponding C source file. The result of ‘$(filter %.elc,$(files))’ is ‘foo.elc’, so that file is made from ‘foo.el’.
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’.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A static pattern rule has much in common with an implicit rule defined as a
pattern rule (see section Defining and Redefining Pattern Rules).
Both have a pattern for the target and patterns for constructing the
names of prerequisites. The difference 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 specified, 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 specified. If two conflicting rules apply, and both have recipes, that’s an error.
The static pattern rule can be better than an implicit rule for these reasons:
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 specified.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Davide Tacchella on November 3, 2010 using texi2html 1.82.