Static pattern rules section rewritten by RMS.

This commit is contained in:
Roland McGrath 1988-05-22 12:29:23 +00:00
parent b718e918d1
commit a20cb3e189

View file

@ -6,7 +6,10 @@
$Header$
$Log$
Revision 1.22 1988/05/20 17:00:49 mcgrath
Revision 1.23 1988/05/22 12:29:23 mcgrath
Static pattern rules section rewritten by RMS.
Revision 1.22 88/05/20 17:00:49 mcgrath
Documented extended static rules.
Revision 1.17 88/05/18 16:26:55 mcgrath
@ -184,8 +187,6 @@ be recompiled, or how. @xref{Running}.
* Implicit:: Implicit rules take over if the makefile doesn't say
how a file is to be remade.
* Static:: Extended static rules provide a compromise between explicit
rules and implicit rule assumptions.
* Archives:: How to use @code{make} to update archive files.
* Missing:: Features of other @code{make}s not supported by GNU @code{make}.
@ -604,6 +605,9 @@ or all the programs described by the makefile. @xref{Goals}.
* Special Targets:: Targets with special built-in meanings.
* Empty Targets:: Real files that are empty--only the date matters.
* Multiple Targets:: When it is useful to have several targets in a rule.
* Static Pattern:: Static pattern rules apply to multiple targets
and can vary the dependencies according to the
target name.
* Multiple Rules:: Using several rules with the same target.
* Double-Colon:: Special kind of rule allowing
several independent rules for one target.
@ -1220,7 +1224,12 @@ both pieces to the suffix list. In practice, suffixes normally begin with
@section Multiple Targets in a Rule
A rule with multiple targets is equivalent to writing many rules, each with
one target, and all identical aside from that. This is useful in two cases.
one target, and all identical aside from that. The same commands apply to
all the targets, but their effects may vary because you can substitute the
actual target name into the command using @samp{$@@}. The rule contributes
the same dependencies to all the targets also.
This is useful in two cases.
@itemize @bullet
@item
@ -1235,8 +1244,9 @@ gives an additional dependency to each of the three object files
mentioned.
@item
Identical commands work for all the targets. The automatic variable
@samp{$@@} can be used to substitute the target to be remade into the
Similar commands work for all the targets. The commands do not need
to be absolutely identical, since the automatic variable @samp{$@@}
can be used to substitute the particular target to be remade into the
commands (@pxref{Automatic}). For example:
@example
@ -1260,7 +1270,117 @@ types of output, one if given @samp{-big} and one if given
@samp{-little}.@refill
@end itemize
@node Multiple Rules, Double-Colon, Multiple Targets, Rules
@ifinfo
Suppose you would like to vary the dependencies according to the target,
much as the variable @samp{$@@} allows you to vary the commands.
You cannot do this with multiple targets in an ordinary rule, but you can
do it with a @dfn{static pattern rule}. @xref{Static Pattern}.
@end ifinfo
@node Static Pattern, Multiple Rules, Multiple Targets, Rules
@section Static Pattern Rules
@cindex static pattern rules
@cindex varying dependencies
@dfn{Static pattern rules} are rules which specify multiple targets and
construct the dependency names for each target based on the target name.
They are more general than ordinary rules with multiple targets because the
targets don't have to have identical dependencies. Their dependencies must
be @emph{analogous}, but not necessarily @emph{identical}.
Here is the syntax of a static pattern rule:
@example
@var{targets}: @var{target-pattern}: @var{dep-patterns} @dots{}
@var{commands}
@dots{}
@end example
@noindent
Here @var{targets} gives the list of targets that the rule applies to. The
targets can contain wildcard characters, just like the targets of ordinary
rules (@pxref{Wildcards}).
The @var{target-pattern} and @var{dep-patterns} say how to compute the
dependencies of each target. Each target is matched against the
@var{target-pattern} to extract a part of the target name, called the
@dfn{stem}. This stem is substituted into each of the @var{dep-patterns}
to make the dependency names (one from each @var{dep-pattern}).
Each pattern normally contains the character @samp{%} just once. When the
@var{target-pattern} matches a target, the @samp{%} can match any part of
the target name; this part is called the @dfn{stem}. The rest of the
pattern must match exactly. For example, the target @file{foo.o} matches
the pattern @samp{%.o}, with @samp{foo} as the stem. The targets
@file{foo.c} and @file{foo.out} don't match that pattern.@refill
The dependency names for each target are made by substituting the stem for
the @samp{%} in each dependency pattern. For example, if one dependency
pattern is @file{%.c}, then substitution of the stem @samp{foo} gives the
dependency name @file{foo.c}. It is fine to write a dependency pattern that
doesn't contain @samp{%}; then this dependency is the same for all targets.
Here is an example, which compiles each of @file{foo.o} and @file{bar.o}
from the corresponding @file{.c} file:
@example
objects := foo.o bar.o
$(objects): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@@
@end example
Each target specified must match the target pattern; a warning is issued
for each that does not. If you have a list of files, only some of which
will match the pattern, you can use the @code{filter} function to remove
nonmatching filenames (@pxref{Functions}):
@example
files := foo.elc bar.o
$(filter %.o,$(files)): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@@
$(filter %.elc,$(files)): %.elc: %.el
emacs -f batch-byte-compile $<
@end example
@subsection Static Pattern Rules versus Implicit Rules
A static pattern rule has much in common with an implicit rule defined as a
pattern rule (@pxref{Pattern Rules}). Both have a pattern for the target
and patterns for constructing the names of dependencies. The difference is
in how @code{make} decides @emph{when} the rule applies.
An implicit rule @emph{can} apply to any target that matches its pattern,
but it @emph{does} apply only when the target has no commands otherwise
specified, and only when the dependencies 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 commands, that's an error.
The static pattern rule can be better than an implicit rule for these
reasons:
@itemize @bullet
@item
You may wish to override the usual implicit rule for a few files whose
names cannot be categorized syntactically but can be given in an
explicit list.
@item
If you cannot be sure of the precise contents of the directories you
are using, you may not be sure which other irrelevant files might lead
@code{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.
@end itemize
@node Multiple Rules, Double-Colon, Static Pattern, Rules
@section Multiple Rules for One Target
One file can be the target of several rules if at most one rule has commands.
@ -3999,76 +4119,7 @@ The name of the first dependency that came via the implicit rule.
For @code{.DEFAULT} commands, as for non-implicit commands, @samp{$*}
and @samp{$<} are empty. @samp{$@@} is @var{t}, as always.
@node Static, Archives, Implicit, Top
@chapter Extended Static Rules
@cindex extended static rules
@cindex static rules
@cindex explicit rules
@dfn{Static rules}, or @dfn{explicit rules} are simple rules where you give
the dependencies and commands for the targets. @dfn{Implicit rules}
(@pxref{Implicit}) are rules generated by @code{make} for which you specify
only the target (and perhaps some implicit rules in addition to the
standard set), and the dependencies and commands are figured out for you.
@dfn{Extended static rules} provide a compromise between these two types of
rules. They have the flexibility of implicit rules, but do not depend on
the contents of any directory to determine what is made from what.
Extended static rules are basically implicit rules that are applied to a
limited set of targets, rather than just any target that has no commands of
its own. The syntax of this type of rule follows directly from this
explanation:
@example
@var{targets}: @var{target-pattern}: @var{dep} @dots{}; @var{command}
@var{command}
@dots{}
@end example
The first part of this rule, ``@var{targets}:'' gives the list of targets
that the rule applies to. These targets are filenames, possibly containing
wildcard characters, just like the targets of ordinary explicit rules.
The rest of the rule resembles an implicit pattern rule. It has a target
pattern containing a @samp{%} character and dependency filenames, each of
which may contain a @samp{%} which is replaced by what matched the @samp{%}
in the target pattern.
In extended static rules, each target must match the target pattern; a
warning is issued for each that does not. If you have a list of files,
only some of which will match the pattern, you can use the @samp{filter}
function to remove nonmatching filenames:
@example
files := foo.elc bar.o
$(filter %.o,$(files)): %.o: %.c; cc $< -o $@@
$(filter %.elc,$(files)): %.elc: %.el; el-compile $< -o $@@
@end example
This type of rule is better than implicit rules in some situations
for a few reasons:
@itemize @bullet
@item
You may wish to have a different pattern rule apply to one set of files
than applies to all others.
@item
If you cannot be sure of the contents of the directories in which your
targets reside (or those listed in @code{vpath} search paths or the
@code{VPATH} variable; @pxref{Directory Search}), you may want to
circumvent possible unintended actions by @code{make} resulting from the
wrong implicit rule matching.
@item
You may simply be of the opinion that implicit rules are inherently not
particularly wonderful and would rather tell @code{make} exactly what to do
with what, but without all the trouble of ordinary explicit rules.
(This is included because that appears to be the opinion of the person who
originally suggested the concept of extended static rules.)
@end itemize
@node Archives, Missing, Static, Top
@node Archives, Missing, Implicit, Top
@chapter Using @code{make} to Update Archive Files
@cindex archive