1873 lines
58 KiB
HTML
1873 lines
58 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<!-- This HTML file has been created by texi2html 1.54
|
|
from ../texi/make.texinfo on 19 July 2000 -->
|
|
|
|
<TITLE>GNU make - Writing Rules</TITLE>
|
|
<link href="make_5.html" rel=Next>
|
|
<link href="make_3.html" rel=Previous>
|
|
<link href="make_toc.html" rel=ToC>
|
|
|
|
</HEAD>
|
|
<BODY>
|
|
<p>Go to the <A HREF="make_1.html">first</A>, <A HREF="make_3.html">previous</A>, <A HREF="make_5.html">next</A>, <A HREF="make_19.html">last</A> section, <A HREF="make_toc.html">table of contents</A>.
|
|
<P><HR><P>
|
|
|
|
|
|
<H1><A NAME="SEC20" HREF="make_toc.html#TOC20">Writing Rules</A></H1>
|
|
<P>
|
|
<A NAME="IDX114"></A>
|
|
<A NAME="IDX115"></A>
|
|
<A NAME="IDX116"></A>
|
|
<A NAME="IDX117"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A <STRONG>rule</STRONG> appears in the makefile and says when and how to remake
|
|
certain files, called the rule's <STRONG>targets</STRONG> (most often only one per rule).
|
|
It lists the other files that are the <STRONG>prerequisites</STRONG> of the target, and
|
|
<STRONG>commands</STRONG> to use to create or update the target.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX118"></A>
|
|
<A NAME="IDX119"></A>
|
|
The order of rules is not significant, except for determining the
|
|
<STRONG>default goal</STRONG>: the target for <CODE>make</CODE> to consider, if you do
|
|
not otherwise specify one. The default goal is the target of the first
|
|
rule in the first makefile. If the first rule has multiple targets,
|
|
only the first target is taken as the default. There are two
|
|
exceptions: a target starting with a period is not a default unless it
|
|
contains one or more slashes, <SAMP>`/'</SAMP>, as well; and, a target that
|
|
defines a pattern rule has no effect on the default goal.
|
|
(See section <A HREF="make_10.html#SEC98">Defining and Redefining Pattern Rules</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
Therefore, we usually write the makefile so that the first rule is the
|
|
one for compiling the entire program or all the programs described by
|
|
the makefile (often with a target called <SAMP>`all'</SAMP>).
|
|
See section <A HREF="make_9.html#SEC87">Arguments to Specify the Goals</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC21" HREF="make_toc.html#TOC21">Rule Syntax</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX120"></A>
|
|
<A NAME="IDX121"></A>
|
|
In general, a rule looks like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>targets</VAR> : <VAR>prerequisites</VAR>
|
|
<VAR>command</VAR>
|
|
...
|
|
</PRE>
|
|
|
|
<P>
|
|
or like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>targets</VAR> : <VAR>prerequisites</VAR> ; <VAR>command</VAR>
|
|
<VAR>command</VAR>
|
|
...
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX122"></A>
|
|
<A NAME="IDX123"></A>
|
|
The <VAR>targets</VAR> are file names, separated by spaces. Wildcard
|
|
characters may be used (see section <A HREF="make_4.html#SEC22">Using Wildcard Characters in File Names</A>) and a name of the form <TT>`<VAR>a</VAR>(<VAR>m</VAR>)'</TT>
|
|
represents member <VAR>m</VAR> in archive file <VAR>a</VAR>
|
|
(see section <A HREF="make_11.html#SEC109">Archive Members as Targets</A>).
|
|
Usually there is only one
|
|
target per rule, but occasionally there is a reason to have more
|
|
(see section <A HREF="make_4.html#SEC37">Multiple Targets in a Rule</A>).
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX124"></A>
|
|
<A NAME="IDX125"></A>
|
|
The <VAR>command</VAR> lines start with a tab character. The first command may
|
|
appear on the line after the prerequisites, with a tab character, or may
|
|
appear on the same line, with a semicolon. Either way, the effect is the
|
|
same. See section <A HREF="make_5.html#SEC44">Writing the Commands in Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX126"></A>
|
|
<A NAME="IDX127"></A>
|
|
<A NAME="IDX128"></A>
|
|
Because dollar signs are used to start variable references, if you really
|
|
want a dollar sign in a rule you must write two of them, <SAMP>`$$'</SAMP>
|
|
(see section <A HREF="make_6.html#SEC57">How to Use Variables</A>).
|
|
You may split a long line by inserting a backslash
|
|
followed by a newline, but this is not required, as <CODE>make</CODE> places no
|
|
limit on the length of a line in a makefile.
|
|
|
|
</P>
|
|
<P>
|
|
A rule tells <CODE>make</CODE> two things: when the targets are out of date,
|
|
and how to update them when necessary.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX129"></A>
|
|
<A NAME="IDX130"></A>
|
|
The criterion for being out of date is specified in terms of the
|
|
<VAR>prerequisites</VAR>, which consist of file names separated by spaces.
|
|
(Wildcards and archive members (see section <A HREF="make_11.html#SEC108">Using <CODE>make</CODE> to Update Archive Files</A>) are allowed here too.)
|
|
A target is out of date if it does not exist or if it is older than any
|
|
of the prerequisites (by comparison of last-modification times). The
|
|
idea is that the contents of the target file are computed based on
|
|
information in the prerequisites, so if any of the prerequisites changes,
|
|
the contents of the existing target file are no longer necessarily
|
|
valid.
|
|
|
|
</P>
|
|
<P>
|
|
How to update is specified by <VAR>commands</VAR>. These are lines to be
|
|
executed by the shell (normally <SAMP>`sh'</SAMP>), but with some extra features
|
|
(see section <A HREF="make_5.html#SEC44">Writing the Commands in Rules</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC22" HREF="make_toc.html#TOC22">Using Wildcard Characters in File Names</A></H2>
|
|
<P>
|
|
<A NAME="IDX131"></A>
|
|
<A NAME="IDX132"></A>
|
|
<A NAME="IDX133"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX134"></A>
|
|
<A NAME="IDX135"></A>
|
|
<A NAME="IDX136"></A>
|
|
A single file name can specify many files using <STRONG>wildcard characters</STRONG>.
|
|
The wildcard characters in <CODE>make</CODE> are <SAMP>`*'</SAMP>, <SAMP>`?'</SAMP> and
|
|
<SAMP>`[...]'</SAMP>, the same as in the Bourne shell. For example, <TT>`*.c'</TT>
|
|
specifies a list of all the files (in the working directory) whose names
|
|
end in <SAMP>`.c'</SAMP>.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX137"></A>
|
|
<A NAME="IDX138"></A>
|
|
<A NAME="IDX139"></A>
|
|
The character <SAMP>`~'</SAMP> at the beginning of a file name also has special
|
|
significance. If alone, or followed by a slash, it represents your home
|
|
directory. For example <TT>`~/bin'</TT> expands to <TT>`/home/you/bin'</TT>.
|
|
If the <SAMP>`~'</SAMP> is followed by a word, the string represents the home
|
|
directory of the user named by that word. For example <TT>`~john/bin'</TT>
|
|
expands to <TT>`/home/john/bin'</TT>. On systems which don't have a home
|
|
directory for each user (such as MS-DOS or MS-Windows), this
|
|
functionality can be simulated by setting the environment variable
|
|
<VAR>HOME</VAR>.
|
|
</P>
|
|
<P>
|
|
Wildcard expansion happens automatically in targets, in prerequisites,
|
|
and in commands (where the shell does the expansion). In other
|
|
contexts, wildcard expansion happens only if you request it explicitly
|
|
with the <CODE>wildcard</CODE> function.
|
|
|
|
</P>
|
|
<P>
|
|
The special significance of a wildcard character can be turned off by
|
|
preceding it with a backslash. Thus, <TT>`foo\*bar'</TT> would refer to a
|
|
specific file whose name consists of <SAMP>`foo'</SAMP>, an asterisk, and
|
|
<SAMP>`bar'</SAMP>.
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC23" HREF="make_toc.html#TOC23">Wildcard Examples</A></H3>
|
|
|
|
<P>
|
|
Wildcards can be used in the commands of a rule, where they are expanded
|
|
by the shell. For example, here is a rule to delete all the object files:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
clean:
|
|
rm -f *.o
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX140"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Wildcards are also useful in the prerequisites of a rule. With the
|
|
following rule in the makefile, <SAMP>`make print'</SAMP> will print all the
|
|
<SAMP>`.c'</SAMP> files that have changed since the last time you printed them:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
print: *.c
|
|
lpr -p $?
|
|
touch print
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX141"></A>
|
|
<A NAME="IDX142"></A>
|
|
<A NAME="IDX143"></A>
|
|
This rule uses <TT>`print'</TT> as an empty target file; see section <A HREF="make_4.html#SEC35">Empty Target Files to Record Events</A>. (The automatic variable
|
|
<SAMP>`$?'</SAMP> is used to print only those files that have changed; see
|
|
section <A HREF="make_10.html#SEC101">Automatic Variables</A>.)
|
|
</P>
|
|
<P>
|
|
Wildcard expansion does not happen when you define a variable. Thus, if
|
|
you write this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = *.o
|
|
</PRE>
|
|
|
|
<P>
|
|
then the value of the variable <CODE>objects</CODE> is the actual string
|
|
<SAMP>`*.o'</SAMP>. However, if you use the value of <CODE>objects</CODE> in a target,
|
|
prerequisite or command, wildcard expansion will take place at that time.
|
|
To set <CODE>objects</CODE> to the expansion, instead use:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects := $(wildcard *.o)
|
|
</PRE>
|
|
|
|
<P>
|
|
See section <A HREF="make_4.html#SEC25">The Function <CODE>wildcard</CODE></A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC24" HREF="make_toc.html#TOC24">Pitfalls of Using Wildcards</A></H3>
|
|
<P>
|
|
<A NAME="IDX144"></A>
|
|
<A NAME="IDX145"></A>
|
|
<A NAME="IDX146"></A>
|
|
<A NAME="IDX147"></A>
|
|
<A NAME="IDX148"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Now here is an example of a naive way of using wildcard expansion, that
|
|
does not do what you would intend. Suppose you would like to say that the
|
|
executable file <TT>`foo'</TT> is made from all the object files in the
|
|
directory, and you write this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = *.o
|
|
|
|
foo : $(objects)
|
|
cc -o foo $(CFLAGS) $(objects)
|
|
</PRE>
|
|
|
|
<P>
|
|
The value of <CODE>objects</CODE> is the actual string <SAMP>`*.o'</SAMP>. Wildcard
|
|
expansion happens in the rule for <TT>`foo'</TT>, so that each <EM>existing</EM>
|
|
<SAMP>`.o'</SAMP> file becomes a prerequisite of <TT>`foo'</TT> and will be recompiled if
|
|
necessary.
|
|
|
|
</P>
|
|
<P>
|
|
But what if you delete all the <SAMP>`.o'</SAMP> files? When a wildcard matches
|
|
no files, it is left as it is, so then <TT>`foo'</TT> will depend on the
|
|
oddly-named file <TT>`*.o'</TT>. Since no such file is likely to exist,
|
|
<CODE>make</CODE> will give you an error saying it cannot figure out how to
|
|
make <TT>`*.o'</TT>. This is not what you want!
|
|
|
|
</P>
|
|
<P>
|
|
Actually it is possible to obtain the desired result with wildcard
|
|
expansion, but you need more sophisticated techniques, including the
|
|
<CODE>wildcard</CODE> function and string substitution.
|
|
These are described in the following section.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX149"></A>
|
|
<A NAME="IDX150"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Microsoft operating systems (MS-DOS and MS-Windows) use backslashes to
|
|
separate directories in pathnames, like so:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
c:\foo\bar\baz.c
|
|
</PRE>
|
|
|
|
<P>
|
|
This is equivalent to the Unix-style <TT>`c:/foo/bar/baz.c'</TT> (the
|
|
<TT>`c:'</TT> part is the so-called drive letter). When <CODE>make</CODE> runs on
|
|
these systems, it supports backslashes as well as the Unix-style forward
|
|
slashes in pathnames. However, this support does <EM>not</EM> include the
|
|
wildcard expansion, where backslash is a quote character. Therefore,
|
|
you <EM>must</EM> use Unix-style slashes in these cases.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC25" HREF="make_toc.html#TOC25">The Function <CODE>wildcard</CODE></A></H3>
|
|
<P>
|
|
<A NAME="IDX151"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Wildcard expansion happens automatically in rules. But wildcard expansion
|
|
does not normally take place when a variable is set, or inside the
|
|
arguments of a function. If you want to do wildcard expansion in such
|
|
places, you need to use the <CODE>wildcard</CODE> function, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(wildcard <VAR>pattern</VAR>...)
|
|
</PRE>
|
|
|
|
<P>
|
|
This string, used anywhere in a makefile, is replaced by a
|
|
space-separated list of names of existing files that match one of the
|
|
given file name patterns. If no existing file name matches a pattern,
|
|
then that pattern is omitted from the output of the <CODE>wildcard</CODE>
|
|
function. Note that this is different from how unmatched wildcards
|
|
behave in rules, where they are used verbatim rather than ignored
|
|
(see section <A HREF="make_4.html#SEC24">Pitfalls of Using Wildcards</A>).
|
|
|
|
</P>
|
|
<P>
|
|
One use of the <CODE>wildcard</CODE> function is to get a list of all the C source
|
|
files in a directory, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(wildcard *.c)
|
|
</PRE>
|
|
|
|
<P>
|
|
We can change the list of C source files into a list of object files by
|
|
replacing the <SAMP>`.c'</SAMP> suffix with <SAMP>`.o'</SAMP> in the result, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(patsubst %.c,%.o,$(wildcard *.c))
|
|
</PRE>
|
|
|
|
<P>
|
|
(Here we have used another function, <CODE>patsubst</CODE>.
|
|
See section <A HREF="make_8.html#SEC77">Functions for String Substitution and Analysis</A>.)
|
|
</P>
|
|
<P>
|
|
Thus, a makefile to compile all C source files in the directory and then
|
|
link them together could be written as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects := $(patsubst %.c,%.o,$(wildcard *.c))
|
|
|
|
foo : $(objects)
|
|
cc -o foo $(objects)
|
|
</PRE>
|
|
|
|
<P>
|
|
(This takes advantage of the implicit rule for compiling C programs, so
|
|
there is no need to write explicit rules for compiling the files.
|
|
See section <A HREF="make_6.html#SEC59">The Two Flavors of Variables</A>, for an explanation of
|
|
<SAMP>`:='</SAMP>, which is a variant of <SAMP>`='</SAMP>.)
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC26" HREF="make_toc.html#TOC26">Searching Directories for Prerequisites</A></H2>
|
|
<P>
|
|
<A NAME="IDX152"></A>
|
|
<A NAME="IDX153"></A>
|
|
<A NAME="IDX154"></A>
|
|
<A NAME="IDX155"></A>
|
|
<A NAME="IDX156"></A>
|
|
|
|
</P>
|
|
<P>
|
|
For large systems, it is often desirable to put sources in a separate
|
|
directory from the binaries. The <STRONG>directory search</STRONG> features of
|
|
<CODE>make</CODE> facilitate this by searching several directories
|
|
automatically to find a prerequisite. When you redistribute the files
|
|
among directories, you do not need to change the individual rules,
|
|
just the search paths.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC27" HREF="make_toc.html#TOC27"><CODE>VPATH</CODE>: Search Path for All Prerequisites</A></H3>
|
|
<P>
|
|
<A NAME="IDX157"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The value of the <CODE>make</CODE> variable <CODE>VPATH</CODE> specifies a list of
|
|
directories that <CODE>make</CODE> should search. Most often, the
|
|
directories are expected to contain prerequisite files that are not in the
|
|
current directory; however, <CODE>VPATH</CODE> specifies a search list that
|
|
<CODE>make</CODE> applies for all files, including files which are targets of
|
|
rules.
|
|
|
|
</P>
|
|
<P>
|
|
Thus, if a file that is listed as a target or prerequisite does not exist
|
|
in the current directory, <CODE>make</CODE> searches the directories listed in
|
|
<CODE>VPATH</CODE> for a file with that name. If a file is found in one of
|
|
them, that file may become the prerequisite (see below). Rules may then
|
|
specify the names of files in the prerequisite list as if they all
|
|
existed in the current directory. See section <A HREF="make_4.html#SEC30">Writing Shell Commands with Directory Search</A>.
|
|
|
|
</P>
|
|
<P>
|
|
In the <CODE>VPATH</CODE> variable, directory names are separated by colons or
|
|
blanks. The order in which directories are listed is the order followed
|
|
by <CODE>make</CODE> in its search. (On MS-DOS and MS-Windows, semi-colons
|
|
are used as separators of directory names in <CODE>VPATH</CODE>, since the
|
|
colon can be used in the pathname itself, after the drive letter.)
|
|
|
|
</P>
|
|
<P>
|
|
For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
VPATH = src:../headers
|
|
</PRE>
|
|
|
|
<P>
|
|
specifies a path containing two directories, <TT>`src'</TT> and
|
|
<TT>`../headers'</TT>, which <CODE>make</CODE> searches in that order.
|
|
|
|
</P>
|
|
<P>
|
|
With this value of <CODE>VPATH</CODE>, the following rule,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o : foo.c
|
|
</PRE>
|
|
|
|
<P>
|
|
is interpreted as if it were written like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o : src/foo.c
|
|
</PRE>
|
|
|
|
<P>
|
|
assuming the file <TT>`foo.c'</TT> does not exist in the current directory but
|
|
is found in the directory <TT>`src'</TT>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC28" HREF="make_toc.html#TOC28">The <CODE>vpath</CODE> Directive</A></H3>
|
|
<P>
|
|
<A NAME="IDX158"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Similar to the <CODE>VPATH</CODE> variable, but more selective, is the
|
|
<CODE>vpath</CODE> directive (note lower case), which allows you to specify a
|
|
search path for a particular class of file names: those that match a
|
|
particular pattern. Thus you can supply certain search directories for
|
|
one class of file names and other directories (or none) for other file
|
|
names.
|
|
|
|
</P>
|
|
<P>
|
|
There are three forms of the <CODE>vpath</CODE> directive:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>vpath <VAR>pattern</VAR> <VAR>directories</VAR></CODE>
|
|
<DD>
|
|
Specify the search path <VAR>directories</VAR> for file names that match
|
|
<VAR>pattern</VAR>.
|
|
|
|
The search path, <VAR>directories</VAR>, is a list of directories to be
|
|
searched, separated by colons (semi-colons on MS-DOS and MS-Windows) or
|
|
blanks, just like the search path used in the <CODE>VPATH</CODE> variable.
|
|
|
|
<DT><CODE>vpath <VAR>pattern</VAR></CODE>
|
|
<DD>
|
|
Clear out the search path associated with <VAR>pattern</VAR>.
|
|
|
|
<DT><CODE>vpath</CODE>
|
|
<DD>
|
|
Clear all search paths previously specified with <CODE>vpath</CODE> directives.
|
|
</DL>
|
|
|
|
<P>
|
|
A <CODE>vpath</CODE> pattern is a string containing a <SAMP>`%'</SAMP> character. The
|
|
string must match the file name of a prerequisite that is being searched
|
|
for, the <SAMP>`%'</SAMP> character matching any sequence of zero or more
|
|
characters (as in pattern rules; see section <A HREF="make_10.html#SEC98">Defining and Redefining Pattern Rules</A>). For example, <CODE>%.h</CODE> matches files that
|
|
end in <CODE>.h</CODE>. (If there is no <SAMP>`%'</SAMP>, the pattern must match the
|
|
prerequisite exactly, which is not useful very often.)
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX159"></A>
|
|
<A NAME="IDX160"></A>
|
|
<A NAME="IDX161"></A>
|
|
<A NAME="IDX162"></A>
|
|
<A NAME="IDX163"></A>
|
|
<SAMP>`%'</SAMP> characters in a <CODE>vpath</CODE> directive's pattern can be quoted
|
|
with preceding backslashes (<SAMP>`\'</SAMP>). Backslashes that would otherwise
|
|
quote <SAMP>`%'</SAMP> characters can be quoted with more backslashes.
|
|
Backslashes that quote <SAMP>`%'</SAMP> characters or other backslashes are
|
|
removed from the pattern before it is compared to file names. Backslashes
|
|
that are not in danger of quoting <SAMP>`%'</SAMP> characters go unmolested.
|
|
</P>
|
|
<P>
|
|
When a prerequisite fails to exist in the current directory, if the
|
|
<VAR>pattern</VAR> in a <CODE>vpath</CODE> directive matches the name of the
|
|
prerequisite file, then the <VAR>directories</VAR> in that directive are searched
|
|
just like (and before) the directories in the <CODE>VPATH</CODE> variable.
|
|
|
|
</P>
|
|
<P>
|
|
For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
vpath %.h ../headers
|
|
</PRE>
|
|
|
|
<P>
|
|
tells <CODE>make</CODE> to look for any prerequisite whose name ends in <TT>`.h'</TT>
|
|
in the directory <TT>`../headers'</TT> if the file is not found in the current
|
|
directory.
|
|
|
|
</P>
|
|
<P>
|
|
If several <CODE>vpath</CODE> patterns match the prerequisite file's name, then
|
|
<CODE>make</CODE> processes each matching <CODE>vpath</CODE> directive one by one,
|
|
searching all the directories mentioned in each directive. <CODE>make</CODE>
|
|
handles multiple <CODE>vpath</CODE> directives in the order in which they
|
|
appear in the makefile; multiple directives with the same pattern are
|
|
independent of each other.
|
|
|
|
</P>
|
|
<P>
|
|
Thus,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
vpath %.c foo
|
|
vpath % blish
|
|
vpath %.c bar
|
|
</PRE>
|
|
|
|
<P>
|
|
will look for a file ending in <SAMP>`.c'</SAMP> in <TT>`foo'</TT>, then
|
|
<TT>`blish'</TT>, then <TT>`bar'</TT>, while
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
vpath %.c foo:bar
|
|
vpath % blish
|
|
</PRE>
|
|
|
|
<P>
|
|
will look for a file ending in <SAMP>`.c'</SAMP> in <TT>`foo'</TT>, then
|
|
<TT>`bar'</TT>, then <TT>`blish'</TT>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC29" HREF="make_toc.html#TOC29">How Directory Searches are Performed</A></H3>
|
|
<P>
|
|
<A NAME="IDX164"></A>
|
|
<A NAME="IDX165"></A>
|
|
|
|
</P>
|
|
<P>
|
|
When a prerequisite is found through directory search, regardless of type
|
|
(general or selective), the pathname located may not be the one that
|
|
<CODE>make</CODE> actually provides you in the prerequisite list. Sometimes
|
|
the path discovered through directory search is thrown away.
|
|
|
|
</P>
|
|
<P>
|
|
The algorithm <CODE>make</CODE> uses to decide whether to keep or abandon a
|
|
path found via directory search is as follows:
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
If a target file does not exist at the path specified in the makefile,
|
|
directory search is performed.
|
|
|
|
<LI>
|
|
|
|
If the directory search is successful, that path is kept and this file
|
|
is tentatively stored as the target.
|
|
|
|
<LI>
|
|
|
|
All prerequisites of this target are examined using this same method.
|
|
|
|
<LI>
|
|
|
|
After processing the prerequisites, the target may or may not need to be
|
|
rebuilt:
|
|
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
If the target does <EM>not</EM> need to be rebuilt, the path to the file
|
|
found during directory search is used for any prerequisite lists which
|
|
contain this target. In short, if <CODE>make</CODE> doesn't need to rebuild
|
|
the target then you use the path found via directory search.
|
|
|
|
<LI>
|
|
|
|
If the target <EM>does</EM> need to be rebuilt (is out-of-date), the
|
|
pathname found during directory search is <EM>thrown away</EM>, and the
|
|
target is rebuilt using the file name specified in the makefile. In
|
|
short, if <CODE>make</CODE> must rebuild, then the target is rebuilt locally,
|
|
not in the directory found via directory search.
|
|
</OL>
|
|
|
|
</OL>
|
|
|
|
<P>
|
|
This algorithm may seem complex, but in practice it is quite often
|
|
exactly what you want.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX166"></A>
|
|
<A NAME="IDX167"></A>
|
|
Other versions of <CODE>make</CODE> use a simpler algorithm: if the file does
|
|
not exist, and it is found via directory search, then that pathname is
|
|
always used whether or not the target needs to be built. Thus, if the
|
|
target is rebuilt it is created at the pathname discovered during
|
|
directory search.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX168"></A>
|
|
If, in fact, this is the behavior you want for some or all of your
|
|
directories, you can use the <CODE>GPATH</CODE> variable to indicate this to
|
|
<CODE>make</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>GPATH</CODE> has the same syntax and format as <CODE>VPATH</CODE> (that is, a
|
|
space- or colon-delimited list of pathnames). If an out-of-date target
|
|
is found by directory search in a directory that also appears in
|
|
<CODE>GPATH</CODE>, then that pathname is not thrown away. The target is
|
|
rebuilt using the expanded path.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC30" HREF="make_toc.html#TOC30">Writing Shell Commands with Directory Search</A></H3>
|
|
<P>
|
|
<A NAME="IDX169"></A>
|
|
<A NAME="IDX170"></A>
|
|
|
|
</P>
|
|
<P>
|
|
When a prerequisite is found in another directory through directory search,
|
|
this cannot change the commands of the rule; they will execute as written.
|
|
Therefore, you must write the commands with care so that they will look for
|
|
the prerequisite in the directory where <CODE>make</CODE> finds it.
|
|
|
|
</P>
|
|
<P>
|
|
This is done with the <STRONG>automatic variables</STRONG> such as <SAMP>`$^'</SAMP>
|
|
(see section <A HREF="make_10.html#SEC101">Automatic Variables</A>).
|
|
For instance, the value of <SAMP>`$^'</SAMP> is a
|
|
list of all the prerequisites of the rule, including the names of
|
|
the directories in which they were found, and the value of
|
|
<SAMP>`$@'</SAMP> is the target. Thus:
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o : foo.c
|
|
cc -c $(CFLAGS) $^ -o $@
|
|
</PRE>
|
|
|
|
<P>
|
|
(The variable <CODE>CFLAGS</CODE> exists so you can specify flags for C
|
|
compilation by implicit rules; we use it here for consistency so it will
|
|
affect all C compilations uniformly;
|
|
see section <A HREF="make_10.html#SEC96">Variables Used by Implicit Rules</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
Often the prerequisites include header files as well, which you do not
|
|
want to mention in the commands. The automatic variable <SAMP>`$<'</SAMP> is
|
|
just the first prerequisite:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
VPATH = src:../headers
|
|
foo.o : foo.c defs.h hack.h
|
|
cc -c $(CFLAGS) $< -o $@
|
|
</PRE>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC31" HREF="make_toc.html#TOC31">Directory Search and Implicit Rules</A></H3>
|
|
<P>
|
|
<A NAME="IDX171"></A>
|
|
<A NAME="IDX172"></A>
|
|
<A NAME="IDX173"></A>
|
|
<A NAME="IDX174"></A>
|
|
<A NAME="IDX175"></A>
|
|
<A NAME="IDX176"></A>
|
|
<A NAME="IDX177"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The search through the directories specified in <CODE>VPATH</CODE> or with
|
|
<CODE>vpath</CODE> also happens during consideration of implicit rules
|
|
(see section <A HREF="make_10.html#SEC93">Using Implicit Rules</A>).
|
|
|
|
</P>
|
|
<P>
|
|
For example, when a file <TT>`foo.o'</TT> has no explicit rule, <CODE>make</CODE>
|
|
considers implicit rules, such as the built-in rule to compile
|
|
<TT>`foo.c'</TT> if that file exists. If such a file is lacking in the
|
|
current directory, the appropriate directories are searched for it. If
|
|
<TT>`foo.c'</TT> exists (or is mentioned in the makefile) in any of the
|
|
directories, the implicit rule for C compilation is applied.
|
|
|
|
</P>
|
|
<P>
|
|
The commands of implicit rules normally use automatic variables as a
|
|
matter of necessity; consequently they will use the file names found by
|
|
directory search with no extra effort.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC32" HREF="make_toc.html#TOC32">Directory Search for Link Libraries</A></H3>
|
|
<P>
|
|
<A NAME="IDX178"></A>
|
|
<A NAME="IDX179"></A>
|
|
<A NAME="IDX180"></A>
|
|
<A NAME="IDX181"></A>
|
|
<A NAME="IDX182"></A>
|
|
<A NAME="IDX183"></A>
|
|
<A NAME="IDX184"></A>
|
|
<A NAME="IDX185"></A>
|
|
<A NAME="IDX186"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Directory search applies in a special way to libraries used with the
|
|
linker. This special feature comes into play when you write a prerequisite
|
|
whose name is of the form <SAMP>`-l<VAR>name</VAR>'</SAMP>. (You can tell something
|
|
strange is going on here because the prerequisite is normally the name of a
|
|
file, and the <EM>file name</EM> of a library generally looks like
|
|
<TT>`lib<VAR>name</VAR>.a'</TT>, not like <SAMP>`-l<VAR>name</VAR>'</SAMP>.)
|
|
</P>
|
|
<P>
|
|
When a prerequisite's name has the form <SAMP>`-l<VAR>name</VAR>'</SAMP>, <CODE>make</CODE>
|
|
handles it specially by searching for the file <TT>`lib<VAR>name</VAR>.so'</TT> in
|
|
the current directory, in directories specified by matching <CODE>vpath</CODE>
|
|
search paths and the <CODE>VPATH</CODE> search path, and then in the
|
|
directories <TT>`/lib'</TT>, <TT>`/usr/lib'</TT>, and <TT>`<VAR>prefix</VAR>/lib'</TT>
|
|
(normally <TT>`/usr/local/lib'</TT>, but MS-DOS/MS-Windows versions of
|
|
<CODE>make</CODE> behave as if <VAR>prefix</VAR> is defined to be the root of the
|
|
DJGPP installation tree).
|
|
|
|
</P>
|
|
<P>
|
|
If that file is not found, then the file <TT>`lib<VAR>name</VAR>.a'</TT> is
|
|
searched for, in the same directories as above.
|
|
|
|
</P>
|
|
<P>
|
|
For example, if there is a <TT>`/usr/lib/libcurses.a'</TT> library on your
|
|
system (and no <TT>`/usr/lib/libcurses.so'</TT> file), then
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo : foo.c -lcurses
|
|
cc $^ -o $@
|
|
</PRE>
|
|
|
|
<P>
|
|
would cause the command <SAMP>`cc foo.c /usr/lib/libcurses.a -o foo'</SAMP> to
|
|
be executed when <TT>`foo'</TT> is older than <TT>`foo.c'</TT> or than
|
|
<TT>`/usr/lib/libcurses.a'</TT>.
|
|
</P>
|
|
<P>
|
|
Although the default set of files to be searched for is
|
|
<TT>`lib<VAR>name</VAR>.so'</TT> and <TT>`lib<VAR>name</VAR>.a'</TT>, this is customizable
|
|
via the <CODE>.LIBPATTERNS</CODE> variable. Each word in the value of this
|
|
variable is a pattern string. When a prerequisite like
|
|
<SAMP>`-l<VAR>name</VAR>'</SAMP> is seen, <CODE>make</CODE> will replace the percent in
|
|
each pattern in the list with <VAR>name</VAR> and perform the above directory
|
|
searches using that library filename. If no library is found, the next
|
|
word in the list will be used.
|
|
|
|
</P>
|
|
<P>
|
|
The default value for <CODE>.LIBPATTERNS</CODE> is "<SAMP>`lib%.so lib%.a'</SAMP>",
|
|
which provides the default behavior described above.
|
|
|
|
</P>
|
|
<P>
|
|
You can turn off link library expansion completely by setting this
|
|
variable to an empty value.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC33" HREF="make_toc.html#TOC33">Phony Targets</A></H2>
|
|
<P>
|
|
<A NAME="IDX187"></A>
|
|
<A NAME="IDX188"></A>
|
|
<A NAME="IDX189"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A phony target is one that is not really the name of a file. It is just a
|
|
name for some commands to be executed when you make an explicit request.
|
|
There are two reasons to use a phony target: to avoid a conflict with
|
|
a file of the same name, and to improve performance.
|
|
|
|
</P>
|
|
<P>
|
|
If you write a rule whose commands will not create the target file, the
|
|
commands will be executed every time the target comes up for remaking.
|
|
Here is an example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
clean:
|
|
rm *.o temp
|
|
</PRE>
|
|
|
|
<P>
|
|
Because the <CODE>rm</CODE> command does not create a file named <TT>`clean'</TT>,
|
|
probably no such file will ever exist. Therefore, the <CODE>rm</CODE> command
|
|
will be executed every time you say <SAMP>`make clean'</SAMP>.
|
|
<A NAME="IDX190"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX191"></A>
|
|
The phony target will cease to work if anything ever does create a file
|
|
named <TT>`clean'</TT> in this directory. Since it has no prerequisites, the
|
|
file <TT>`clean'</TT> would inevitably be considered up to date, and its
|
|
commands would not be executed. To avoid this problem, you can explicitly
|
|
declare the target to be phony, using the special target <CODE>.PHONY</CODE>
|
|
(see section <A HREF="make_4.html#SEC36">Special Built-in Target Names</A>) as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.PHONY : clean
|
|
</PRE>
|
|
|
|
<P>
|
|
Once this is done, <SAMP>`make clean'</SAMP> will run the commands regardless of
|
|
whether there is a file named <TT>`clean'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
Since it knows that phony targets do not name actual files that could be
|
|
remade from other files, <CODE>make</CODE> skips the implicit rule search for
|
|
phony targets (see section <A HREF="make_10.html#SEC93">Using Implicit Rules</A>). This is why declaring a target
|
|
phony is good for performance, even if you are not worried about the
|
|
actual file existing.
|
|
|
|
</P>
|
|
<P>
|
|
Thus, you first write the line that states that <CODE>clean</CODE> is a
|
|
phony target, then you write the rule, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.PHONY: clean
|
|
clean:
|
|
rm *.o temp
|
|
</PRE>
|
|
|
|
<P>
|
|
Another example of the usefulness of phony targets is in conjunction
|
|
with recursive invocations of <CODE>make</CODE>. In this case the makefile
|
|
will often contain a variable which lists a number of subdirectories to
|
|
be built. One way to handle this is with one rule whose command is a
|
|
shell loop over the subdirectories, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SUBDIRS = foo bar baz
|
|
|
|
subdirs:
|
|
for dir in $(SUBDIRS); do \
|
|
$(MAKE) -C $$dir; \
|
|
done
|
|
</PRE>
|
|
|
|
<P>
|
|
There are a few of problems with this method, however. First, any error
|
|
detected in a submake is not noted by this rule, so it will continue to
|
|
build the rest of the directories even when one fails. This can be
|
|
overcome by adding shell commands to note the error and exit, but then
|
|
it will do so even if <CODE>make</CODE> is invoked with the <CODE>-k</CODE> option,
|
|
which is unfortunate. Second, and perhaps more importantly, you cannot
|
|
take advantage of the parallel build capabilities of make using this
|
|
method, since there is only one rule.
|
|
|
|
</P>
|
|
<P>
|
|
By declaring the subdirectories as phony targets (you must do this as
|
|
the subdirectory obviously always exists; otherwise it won't be built)
|
|
you can remove these problems:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SUBDIRS = foo bar baz
|
|
|
|
.PHONY: subdirs $(SUBDIRS)
|
|
|
|
subdirs: $(SUBDIRS)
|
|
|
|
$(SUBDIRS):
|
|
$(MAKE) -C $
|
|
|
|
foo: baz
|
|
</PRE>
|
|
|
|
<P>
|
|
Here we've also declared that the <TT>`foo'</TT> subdirectory cannot be
|
|
built until after the <TT>`baz'</TT> subdirectory is complete; this kind of
|
|
relationship declaration is particularly important when attempting
|
|
parallel builds.
|
|
|
|
</P>
|
|
<P>
|
|
A phony target should not be a prerequisite of a real target file; if it
|
|
is, its commands are run every time <CODE>make</CODE> goes to update that
|
|
file. As long as a phony target is never a prerequisite of a real
|
|
target, the phony target commands will be executed only when the phony
|
|
target is a specified goal (see section <A HREF="make_9.html#SEC87">Arguments to Specify the Goals</A>).
|
|
|
|
</P>
|
|
<P>
|
|
Phony targets can have prerequisites. When one directory contains multiple
|
|
programs, it is most convenient to describe all of the programs in one
|
|
makefile <TT>`./Makefile'</TT>. Since the target remade by default will be the
|
|
first one in the makefile, it is common to make this a phony target named
|
|
<SAMP>`all'</SAMP> and give it, as prerequisites, all the individual programs. For
|
|
example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
all : prog1 prog2 prog3
|
|
.PHONY : all
|
|
|
|
prog1 : prog1.o utils.o
|
|
cc -o prog1 prog1.o utils.o
|
|
|
|
prog2 : prog2.o
|
|
cc -o prog2 prog2.o
|
|
|
|
prog3 : prog3.o sort.o utils.o
|
|
cc -o prog3 prog3.o sort.o utils.o
|
|
</PRE>
|
|
|
|
<P>
|
|
Now you can say just <SAMP>`make'</SAMP> to remake all three programs, or specify
|
|
as arguments the ones to remake (as in <SAMP>`make prog1 prog3'</SAMP>).
|
|
|
|
</P>
|
|
<P>
|
|
When one phony target is a prerequisite of another, it serves as a subroutine
|
|
of the other. For example, here <SAMP>`make cleanall'</SAMP> will delete the
|
|
object files, the difference files, and the file <TT>`program'</TT>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.PHONY: cleanall cleanobj cleandiff
|
|
|
|
cleanall : cleanobj cleandiff
|
|
rm program
|
|
|
|
cleanobj :
|
|
rm *.o
|
|
|
|
cleandiff :
|
|
rm *.diff
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC34" HREF="make_toc.html#TOC34">Rules without Commands or Prerequisites</A></H2>
|
|
<P>
|
|
<A NAME="IDX192"></A>
|
|
<A NAME="IDX193"></A>
|
|
<A NAME="IDX194"></A>
|
|
<A NAME="IDX195"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If a rule has no prerequisites or commands, and the target of the rule
|
|
is a nonexistent file, then <CODE>make</CODE> imagines this target to have
|
|
been updated whenever its rule is run. This implies that all targets
|
|
depending on this one will always have their commands run.
|
|
|
|
</P>
|
|
<P>
|
|
An example will illustrate this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
clean: FORCE
|
|
rm $(objects)
|
|
FORCE:
|
|
</PRE>
|
|
|
|
<P>
|
|
Here the target <SAMP>`FORCE'</SAMP> satisfies the special conditions, so the
|
|
target <TT>`clean'</TT> that depends on it is forced to run its commands.
|
|
There is nothing special about the name <SAMP>`FORCE'</SAMP>, but that is one name
|
|
commonly used this way.
|
|
|
|
</P>
|
|
<P>
|
|
As you can see, using <SAMP>`FORCE'</SAMP> this way has the same results as using
|
|
<SAMP>`.PHONY: clean'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Using <SAMP>`.PHONY'</SAMP> is more explicit and more efficient. However,
|
|
other versions of <CODE>make</CODE> do not support <SAMP>`.PHONY'</SAMP>; thus
|
|
<SAMP>`FORCE'</SAMP> appears in many makefiles. See section <A HREF="make_4.html#SEC33">Phony Targets</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC35" HREF="make_toc.html#TOC35">Empty Target Files to Record Events</A></H2>
|
|
<P>
|
|
<A NAME="IDX196"></A>
|
|
<A NAME="IDX197"></A>
|
|
<A NAME="IDX198"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <STRONG>empty target</STRONG> is a variant of the phony target; it is used to hold
|
|
commands for an action that you request explicitly from time to time.
|
|
Unlike a phony target, this target file can really exist; but the file's
|
|
contents do not matter, and usually are empty.
|
|
|
|
</P>
|
|
<P>
|
|
The purpose of the empty target file is to record, with its
|
|
last-modification time, when the rule's commands were last executed. It
|
|
does so because one of the commands is a <CODE>touch</CODE> command to update the
|
|
target file.
|
|
|
|
</P>
|
|
<P>
|
|
The empty target file should have some prerequisites (otherwise it
|
|
doesn't make sense). When you ask to remake the empty target, the
|
|
commands are executed if any prerequisite is more recent than the target;
|
|
in other words, if a prerequisite has changed since the last time you
|
|
remade the target. Here is an example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
print: foo.c bar.c
|
|
lpr -p $?
|
|
touch print
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX199"></A>
|
|
<A NAME="IDX200"></A>
|
|
<A NAME="IDX201"></A>
|
|
|
|
</P>
|
|
<P>
|
|
With this rule, <SAMP>`make print'</SAMP> will execute the <CODE>lpr</CODE> command if
|
|
either source file has changed since the last <SAMP>`make print'</SAMP>. The
|
|
automatic variable <SAMP>`$?'</SAMP> is used to print only those files that have
|
|
changed (see section <A HREF="make_10.html#SEC101">Automatic Variables</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC36" HREF="make_toc.html#TOC36">Special Built-in Target Names</A></H2>
|
|
<P>
|
|
<A NAME="IDX202"></A>
|
|
<A NAME="IDX203"></A>
|
|
<A NAME="IDX204"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Certain names have special meanings if they appear as targets.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>.PHONY</CODE>
|
|
<DD>
|
|
<A NAME="IDX205"></A>
|
|
|
|
|
|
The prerequisites of the special target <CODE>.PHONY</CODE> are considered to
|
|
be phony targets. When it is time to consider such a target,
|
|
<CODE>make</CODE> will run its commands unconditionally, regardless of
|
|
whether a file with that name exists or what its last-modification
|
|
time is. See section <A HREF="make_4.html#SEC33">Phony Targets</A>.
|
|
|
|
<A NAME="IDX206"></A>
|
|
<DT><CODE>.SUFFIXES</CODE>
|
|
<DD>
|
|
The prerequisites of the special target <CODE>.SUFFIXES</CODE> are the list
|
|
of suffixes to be used in checking for suffix rules.
|
|
See section <A HREF="make_10.html#SEC106">Old-Fashioned Suffix Rules</A>.
|
|
|
|
<A NAME="IDX207"></A>
|
|
<DT><CODE>.DEFAULT</CODE>
|
|
<DD>
|
|
The commands specified for <CODE>.DEFAULT</CODE> are used for any target for
|
|
which no rules are found (either explicit rules or implicit rules).
|
|
See section <A HREF="make_10.html#SEC105">Defining Last-Resort Default Rules</A>. If <CODE>.DEFAULT</CODE> commands are specified, every
|
|
file mentioned as a prerequisite, but not as a target in a rule, will have
|
|
these commands executed on its behalf. See section <A HREF="make_10.html#SEC107">Implicit Rule Search Algorithm</A>.
|
|
|
|
<A NAME="IDX208"></A>
|
|
<DT><CODE>.PRECIOUS</CODE>
|
|
<DD>
|
|
<A NAME="IDX209"></A>
|
|
<A NAME="IDX210"></A>
|
|
|
|
The targets which <CODE>.PRECIOUS</CODE> depends on are given the following
|
|
special treatment: if <CODE>make</CODE> is killed or interrupted during the
|
|
execution of their commands, the target is not deleted.
|
|
See section <A HREF="make_5.html#SEC49">Interrupting or Killing <CODE>make</CODE></A>. Also, if the
|
|
target is an intermediate file, it will not be deleted after it is no
|
|
longer needed, as is normally done. See section <A HREF="make_10.html#SEC97">Chains of Implicit Rules</A>. In this latter respect it overlaps with the
|
|
<CODE>.SECONDARY</CODE> special target.
|
|
|
|
You can also list the target pattern of an implicit rule (such as
|
|
<SAMP>`%.o'</SAMP>) as a prerequisite file of the special target <CODE>.PRECIOUS</CODE>
|
|
to preserve intermediate files created by rules whose target patterns
|
|
match that file's name.
|
|
|
|
<A NAME="IDX211"></A>
|
|
<DT><CODE>.INTERMEDIATE</CODE>
|
|
<DD>
|
|
<A NAME="IDX212"></A>
|
|
|
|
The targets which <CODE>.INTERMEDIATE</CODE> depends on are treated as
|
|
intermediate files. See section <A HREF="make_10.html#SEC97">Chains of Implicit Rules</A>.
|
|
<CODE>.INTERMEDIATE</CODE> with no prerequisites has no effect.
|
|
|
|
<A NAME="IDX213"></A>
|
|
<DT><CODE>.SECONDARY</CODE>
|
|
<DD>
|
|
<A NAME="IDX214"></A>
|
|
<A NAME="IDX215"></A>
|
|
|
|
The targets which <CODE>.SECONDARY</CODE> depends on are treated as
|
|
intermediate files, except that they are never automatically deleted.
|
|
See section <A HREF="make_10.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
<CODE>.SECONDARY</CODE> with no prerequisites causes all targets to be treated
|
|
as secondary (i.e., no target is removed because it is considered
|
|
intermediate).
|
|
|
|
<A NAME="IDX216"></A>
|
|
<DT><CODE>.DELETE_ON_ERROR</CODE>
|
|
<DD>
|
|
<A NAME="IDX217"></A>
|
|
|
|
If <CODE>.DELETE_ON_ERROR</CODE> is mentioned as a target anywhere in the
|
|
makefile, then <CODE>make</CODE> will delete the target of a rule if it has
|
|
changed and its commands exit with a nonzero exit status, just as it
|
|
does when it receives a signal. See section <A HREF="make_5.html#SEC48">Errors in Commands</A>.
|
|
|
|
<A NAME="IDX218"></A>
|
|
<DT><CODE>.IGNORE</CODE>
|
|
<DD>
|
|
If you specify prerequisites for <CODE>.IGNORE</CODE>, then <CODE>make</CODE> will
|
|
ignore errors in execution of the commands run for those particular
|
|
files. The commands for <CODE>.IGNORE</CODE> are not meaningful.
|
|
|
|
If mentioned as a target with no prerequisites, <CODE>.IGNORE</CODE> says to
|
|
ignore errors in execution of commands for all files. This usage of
|
|
<SAMP>`.IGNORE'</SAMP> is supported only for historical compatibility. Since
|
|
this affects every command in the makefile, it is not very useful; we
|
|
recommend you use the more selective ways to ignore errors in specific
|
|
commands. See section <A HREF="make_5.html#SEC48">Errors in Commands</A>.
|
|
|
|
<A NAME="IDX219"></A>
|
|
<DT><CODE>.SILENT</CODE>
|
|
<DD>
|
|
If you specify prerequisites for <CODE>.SILENT</CODE>, then <CODE>make</CODE> will
|
|
not print the commands to remake those particular files before executing
|
|
them. The commands for <CODE>.SILENT</CODE> are not meaningful.
|
|
|
|
If mentioned as a target with no prerequisites, <CODE>.SILENT</CODE> says not
|
|
to print any commands before executing them. This usage of
|
|
<SAMP>`.SILENT'</SAMP> is supported only for historical compatibility. We
|
|
recommend you use the more selective ways to silence specific commands.
|
|
See section <A HREF="make_5.html#SEC45">Command Echoing</A>. If you want to silence all commands
|
|
for a particular run of <CODE>make</CODE>, use the <SAMP>`-s'</SAMP> or
|
|
<SAMP>`--silent'</SAMP> option (see section <A HREF="make_9.html#SEC92">Summary of Options</A>).
|
|
|
|
<A NAME="IDX220"></A>
|
|
<DT><CODE>.EXPORT_ALL_VARIABLES</CODE>
|
|
<DD>
|
|
Simply by being mentioned as a target, this tells <CODE>make</CODE> to
|
|
export all variables to child processes by default.
|
|
See section <A HREF="make_5.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>.
|
|
|
|
<A NAME="IDX221"></A>
|
|
<DT><CODE>.NOTPARALLEL</CODE>
|
|
<DD>
|
|
<A NAME="IDX222"></A>
|
|
|
|
If <CODE>.NOTPARALLEL</CODE> is mentioned as a target, then this invocation of
|
|
<CODE>make</CODE> will be run serially, even if the <SAMP>`-j'</SAMP> option is
|
|
given. Any recursively invoked <CODE>make</CODE> command will still be run in
|
|
parallel (unless its makefile contains this target). Any prerequisites
|
|
on this target are ignored.
|
|
</DL>
|
|
|
|
<P>
|
|
Any defined implicit rule suffix also counts as a special target if it
|
|
appears as a target, and so does the concatenation of two suffixes, such
|
|
as <SAMP>`.c.o'</SAMP>. These targets are suffix rules, an obsolete way of
|
|
defining 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 suffix list. In practice, suffixes normally begin with
|
|
<SAMP>`.'</SAMP>, so these special target names also begin with <SAMP>`.'</SAMP>.
|
|
See section <A HREF="make_10.html#SEC106">Old-Fashioned Suffix Rules</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC37" HREF="make_toc.html#TOC37">Multiple Targets in a Rule</A></H2>
|
|
<P>
|
|
<A NAME="IDX223"></A>
|
|
<A NAME="IDX224"></A>
|
|
<A NAME="IDX225"></A>
|
|
<A NAME="IDX226"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A rule with multiple targets is equivalent to writing many rules, each with
|
|
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>`$@'</SAMP>. The rule contributes
|
|
the same prerequisites to all the targets also.
|
|
|
|
</P>
|
|
<P>
|
|
This is useful in two cases.
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
You want just prerequisites, no commands. For example:
|
|
|
|
|
|
<PRE>
|
|
kbd.o command.o files.o: command.h
|
|
</PRE>
|
|
|
|
gives an additional prerequisite to each of the three object files
|
|
mentioned.
|
|
|
|
<LI>
|
|
|
|
Similar commands work for all the targets. The commands do not need
|
|
to be absolutely identical, since the automatic variable <SAMP>`$@'</SAMP>
|
|
can be used to substitute the particular target to be remade into the
|
|
commands (see section <A HREF="make_10.html#SEC101">Automatic Variables</A>). For example:
|
|
|
|
|
|
<PRE>
|
|
bigoutput littleoutput : text.g
|
|
generate text.g -$(subst output,,$@) > $@
|
|
</PRE>
|
|
|
|
<A NAME="IDX227"></A>
|
|
|
|
is equivalent to
|
|
|
|
|
|
<PRE>
|
|
bigoutput : text.g
|
|
generate text.g -big > bigoutput
|
|
littleoutput : text.g
|
|
generate text.g -little > littleoutput
|
|
</PRE>
|
|
|
|
Here we assume the hypothetical program <CODE>generate</CODE> makes two
|
|
types of output, one if given <SAMP>`-big'</SAMP> and one if given
|
|
<SAMP>`-little'</SAMP>.
|
|
See section <A HREF="make_8.html#SEC77">Functions for String Substitution and Analysis</A>,
|
|
for an explanation of the <CODE>subst</CODE> function.
|
|
</UL>
|
|
|
|
<P>
|
|
Suppose you would like to vary the prerequisites according to the target,
|
|
much as the variable <SAMP>`$@'</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 <STRONG>static pattern rule</STRONG>.
|
|
See section <A HREF="make_4.html#SEC39">Static Pattern Rules</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC38" HREF="make_toc.html#TOC38">Multiple Rules for One Target</A></H2>
|
|
<P>
|
|
<A NAME="IDX228"></A>
|
|
<A NAME="IDX229"></A>
|
|
<A NAME="IDX230"></A>
|
|
<A NAME="IDX231"></A>
|
|
|
|
</P>
|
|
<P>
|
|
One file 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 commands are executed.
|
|
|
|
</P>
|
|
<P>
|
|
There can only be one set of commands to be executed for a file.
|
|
If more than one rule gives commands for the same file,
|
|
<CODE>make</CODE> uses the last set given and prints an error message.
|
|
(As a special case, if the file's name begins with a dot, no
|
|
error message is printed. This odd behavior is only for
|
|
compatibility with other implementations of <CODE>make</CODE>.)
|
|
There is no reason to
|
|
write your makefiles this way; that is why <CODE>make</CODE> gives you
|
|
an error message.
|
|
</P>
|
|
<P>
|
|
An extra rule with just prerequisites can be used to give a few extra
|
|
prerequisites to many files at once. For example, one usually has a
|
|
variable named <CODE>objects</CODE> containing a list of all the compiler output
|
|
files in the system being made. An easy way to say that all of them must
|
|
be recompiled if <TT>`config.h'</TT> changes is to write the following:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = foo.o bar.o
|
|
foo.o : defs.h
|
|
bar.o : defs.h test.h
|
|
$(objects) : config.h
|
|
</PRE>
|
|
|
|
<P>
|
|
This could be inserted or taken out without changing the rules that really
|
|
specify how to make the object files, making it a convenient form to use if
|
|
you wish to add the additional prerequisite intermittently.
|
|
|
|
</P>
|
|
<P>
|
|
Another wrinkle is that the additional prerequisites could be specified with
|
|
a variable that you set with a command argument to <CODE>make</CODE>
|
|
(see section <A HREF="make_9.html#SEC90">Overriding Variables</A>). For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
extradeps=
|
|
$(objects) : $(extradeps)
|
|
</PRE>
|
|
|
|
<P>
|
|
means that the command <SAMP>`make extradeps=foo.h'</SAMP> will consider
|
|
<TT>`foo.h'</TT> as a prerequisite of each object file, but plain <SAMP>`make'</SAMP>
|
|
will not.
|
|
|
|
</P>
|
|
<P>
|
|
If none of the explicit rules for a target has commands, then <CODE>make</CODE>
|
|
searches for an applicable implicit rule to find some commands
|
|
see section <A HREF="make_10.html#SEC93">Using Implicit Rules</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC39" HREF="make_toc.html#TOC39">Static Pattern Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX232"></A>
|
|
<A NAME="IDX233"></A>
|
|
<A NAME="IDX234"></A>
|
|
<A NAME="IDX235"></A>
|
|
<A NAME="IDX236"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Static pattern rules</STRONG> 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 <EM>analogous</EM>, but not necessarily <EM>identical</EM>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC40" HREF="make_toc.html#TOC40">Syntax of Static Pattern Rules</A></H3>
|
|
<P>
|
|
<A NAME="IDX237"></A>
|
|
<A NAME="IDX238"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here is the syntax of a static pattern rule:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>targets</VAR> ...: <VAR>target-pattern</VAR>: <VAR>dep-patterns</VAR> ...
|
|
<VAR>commands</VAR>
|
|
...
|
|
</PRE>
|
|
|
|
<P>
|
|
The <VAR>targets</VAR> list specifies the targets that the rule applies to.
|
|
The targets can contain wildcard characters, just like the targets of
|
|
ordinary rules (see section <A HREF="make_4.html#SEC22">Using Wildcard Characters in File Names</A>).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX239"></A>
|
|
<A NAME="IDX240"></A>
|
|
The <VAR>target-pattern</VAR> and <VAR>dep-patterns</VAR> say how to compute the
|
|
prerequisites of each target. Each target is matched against the
|
|
<VAR>target-pattern</VAR> to extract a part of the target name, called the
|
|
<STRONG>stem</STRONG>. This stem is substituted into each of the <VAR>dep-patterns</VAR>
|
|
to make the prerequisite names (one from each <VAR>dep-pattern</VAR>).
|
|
|
|
</P>
|
|
<P>
|
|
Each pattern normally contains the character <SAMP>`%'</SAMP> just once. When the
|
|
<VAR>target-pattern</VAR> matches a target, the <SAMP>`%'</SAMP> can match any part of
|
|
the target name; this part is called the <STRONG>stem</STRONG>. The rest of the
|
|
pattern must match exactly. For example, the target <TT>`foo.o'</TT> matches
|
|
the pattern <SAMP>`%.o'</SAMP>, with <SAMP>`foo'</SAMP> as the stem. The targets
|
|
<TT>`foo.c'</TT> and <TT>`foo.out'</TT> do not match that pattern.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX241"></A>
|
|
The prerequisite names for each target are made by substituting the stem
|
|
for the <SAMP>`%'</SAMP> in each prerequisite pattern. For example, if one
|
|
prerequisite pattern is <TT>`%.c'</TT>, then substitution of the stem
|
|
<SAMP>`foo'</SAMP> gives the prerequisite name <TT>`foo.c'</TT>. It is legitimate
|
|
to write a prerequisite pattern that does not contain <SAMP>`%'</SAMP>; then this
|
|
prerequisite is the same for all targets.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX242"></A>
|
|
<A NAME="IDX243"></A>
|
|
<A NAME="IDX244"></A>
|
|
<A NAME="IDX245"></A>
|
|
<A NAME="IDX246"></A>
|
|
<SAMP>`%'</SAMP> characters in pattern rules can be quoted with preceding
|
|
backslashes (<SAMP>`\'</SAMP>). Backslashes that would otherwise quote <SAMP>`%'</SAMP>
|
|
characters can be quoted with more backslashes. Backslashes that quote
|
|
<SAMP>`%'</SAMP> 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 <SAMP>`%'</SAMP> characters go
|
|
unmolested. For example, the pattern <TT>`the\%weird\\%pattern\\'</TT> has
|
|
<SAMP>`the%weird\'</SAMP> preceding the operative <SAMP>`%'</SAMP> character, and
|
|
<SAMP>`pattern\\'</SAMP> following it. The final two backslashes are left alone
|
|
because they cannot affect any <SAMP>`%'</SAMP> character.
|
|
</P>
|
|
<P>
|
|
Here is an example, which compiles each of <TT>`foo.o'</TT> and <TT>`bar.o'</TT>
|
|
from the corresponding <TT>`.c'</TT> file:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = foo.o bar.o
|
|
|
|
all: $(objects)
|
|
|
|
$(objects): %.o: %.c
|
|
$(CC) -c $(CFLAGS) $< -o $@
|
|
</PRE>
|
|
|
|
<P>
|
|
Here <SAMP>`$<'</SAMP> is the automatic variable that holds the name of the
|
|
prerequisite and <SAMP>`$@'</SAMP> is the automatic variable that holds the name
|
|
of the target; see section <A HREF="make_10.html#SEC101">Automatic Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
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 <CODE>filter</CODE> function to
|
|
remove nonmatching file names (see section <A HREF="make_8.html#SEC77">Functions for String Substitution and Analysis</A>):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
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 $<
|
|
</PRE>
|
|
|
|
<P>
|
|
In this example the result of <SAMP>`$(filter %.o,$(files))'</SAMP> is
|
|
<TT>`bar.o lose.o'</TT>, 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 <SAMP>`$(filter %.elc,$(files))'</SAMP> is
|
|
<TT>`foo.elc'</TT>, so that file is made from <TT>`foo.el'</TT>.
|
|
</P>
|
|
<P>
|
|
Another example shows how to use <CODE>$*</CODE> in static pattern rules:
|
|
<A NAME="IDX247"></A>
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
bigoutput littleoutput : %output : text.g
|
|
generate text.g -$* > $@
|
|
</PRE>
|
|
|
|
<P>
|
|
When the <CODE>generate</CODE> command is run, <CODE>$*</CODE> will expand to the
|
|
stem, either <SAMP>`big'</SAMP> or <SAMP>`little'</SAMP>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC41" HREF="make_toc.html#TOC41">Static Pattern Rules versus Implicit Rules</A></H3>
|
|
<P>
|
|
<A NAME="IDX248"></A>
|
|
<A NAME="IDX249"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A static pattern rule has much in common with an implicit rule defined as a
|
|
pattern rule (see section <A HREF="make_10.html#SEC98">Defining and Redefining Pattern Rules</A>).
|
|
Both have a pattern for the target and patterns for constructing the
|
|
names of prerequisites. The difference is in how <CODE>make</CODE> decides
|
|
<EM>when</EM> the rule applies.
|
|
|
|
</P>
|
|
<P>
|
|
An implicit rule <EM>can</EM> apply to any target that matches its pattern,
|
|
but it <EM>does</EM> apply only when the target has no commands 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.
|
|
|
|
</P>
|
|
<P>
|
|
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.
|
|
|
|
</P>
|
|
<P>
|
|
The static pattern rule can be better than an implicit rule for these
|
|
reasons:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
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.
|
|
|
|
<LI>
|
|
|
|
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</CODE> 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.
|
|
</UL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC42" HREF="make_toc.html#TOC42">Double-Colon Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX250"></A>
|
|
<A NAME="IDX251"></A>
|
|
<A NAME="IDX252"></A>
|
|
<A NAME="IDX253"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Double-colon</STRONG> rules are rules written with <SAMP>`::'</SAMP> instead of
|
|
<SAMP>`:'</SAMP> after the target names. They are handled differently from
|
|
ordinary rules when the same target appears in more than one rule.
|
|
|
|
</P>
|
|
<P>
|
|
When a target appears in multiple rules, all the 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 commands are
|
|
executed if the target is older than any prerequisites of that rule. This
|
|
can result in executing none, any, or all of the double-colon rules.
|
|
|
|
</P>
|
|
<P>
|
|
Double-colon rules with the same target are in fact completely separate
|
|
from one another. Each double-colon rule is processed individually, just
|
|
as rules with different targets are processed.
|
|
|
|
</P>
|
|
<P>
|
|
The double-colon rules for a target are executed in the order they appear
|
|
in the makefile. However, the cases where double-colon rules really make
|
|
sense are those where the order of executing the commands would not matter.
|
|
|
|
</P>
|
|
<P>
|
|
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
|
|
differs depending on which prerequisite files caused the update, and such
|
|
cases are rare.
|
|
|
|
</P>
|
|
<P>
|
|
Each double-colon rule should specify commands; if it does not, an
|
|
implicit rule will be used if one applies.
|
|
See section <A HREF="make_10.html#SEC93">Using Implicit Rules</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC43" HREF="make_toc.html#TOC43">Generating Prerequisites Automatically</A></H2>
|
|
<P>
|
|
<A NAME="IDX254"></A>
|
|
<A NAME="IDX255"></A>
|
|
<A NAME="IDX256"></A>
|
|
|
|
</P>
|
|
<P>
|
|
In the makefile for a program, many of the rules you need to write often
|
|
say only that some object file depends on some header
|
|
file. For example, if <TT>`main.c'</TT> uses <TT>`defs.h'</TT> via an
|
|
<CODE>#include</CODE>, you would write:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
main.o: defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
You need this rule so that <CODE>make</CODE> knows that it must remake
|
|
<TT>`main.o'</TT> whenever <TT>`defs.h'</TT> changes. You can see that for a
|
|
large program you would have to write dozens of such rules in your
|
|
makefile. And, you must always be very careful to update the makefile
|
|
every time you add or remove an <CODE>#include</CODE>.
|
|
<A NAME="IDX257"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX258"></A>
|
|
To avoid this hassle, most modern C compilers can write these rules for
|
|
you, by looking at the <CODE>#include</CODE> lines in the source files.
|
|
Usually this is done with the <SAMP>`-M'</SAMP> option to the compiler.
|
|
For example, the command:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cc -M main.c
|
|
</PRE>
|
|
|
|
<P>
|
|
generates the output:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
main.o : main.c defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
Thus you no longer have to write all those rules yourself.
|
|
The compiler will do it for you.
|
|
|
|
</P>
|
|
<P>
|
|
Note that such a prerequisite constitutes mentioning <TT>`main.o'</TT> in a
|
|
makefile, so it can never be considered an intermediate file by implicit
|
|
rule search. This means that <CODE>make</CODE> won't ever remove the file
|
|
after using it; see section <A HREF="make_10.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX259"></A>
|
|
With old <CODE>make</CODE> programs, it was traditional practice to use this
|
|
compiler feature to generate prerequisites on demand with a command like
|
|
<SAMP>`make depend'</SAMP>. That command would create a file <TT>`depend'</TT>
|
|
containing all the automatically-generated prerequisites; then the
|
|
makefile could use <CODE>include</CODE> to read them in (see section <A HREF="make_3.html#SEC15">Including Other Makefiles</A>).
|
|
|
|
</P>
|
|
<P>
|
|
In GNU <CODE>make</CODE>, the feature of remaking makefiles makes this
|
|
practice obsolete--you need never tell <CODE>make</CODE> explicitly to
|
|
regenerate the prerequisites, because it always regenerates any makefile
|
|
that is out of date. See section <A HREF="make_3.html#SEC17">How Makefiles Are Remade</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The practice we recommend for automatic prerequisite generation is to have
|
|
one makefile corresponding to each source file. For each source file
|
|
<TT>`<VAR>name</VAR>.c'</TT> there is a makefile <TT>`<VAR>name</VAR>.d'</TT> which lists
|
|
what files the object file <TT>`<VAR>name</VAR>.o'</TT> depends on. That way
|
|
only the source files that have changed need to be rescanned to produce
|
|
the new prerequisites.
|
|
|
|
</P>
|
|
<P>
|
|
Here is the pattern rule to generate a file of prerequisites (i.e., a makefile)
|
|
called <TT>`<VAR>name</VAR>.d'</TT> from a C source file called <TT>`<VAR>name</VAR>.c'</TT>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%.d: %.c
|
|
set -e; $(CC) -M $(CPPFLAGS) $< \
|
|
| sed 's/\($*\)\.o[ :]*/\1.o $@ : /g' > $@; \
|
|
[ -s $@ ] || rm -f $@
|
|
</PRE>
|
|
|
|
<P>
|
|
See section <A HREF="make_10.html#SEC98">Defining and Redefining Pattern Rules</A>, for information on defining pattern rules. The
|
|
<SAMP>`-e'</SAMP> flag to the shell makes it exit immediately if the
|
|
<CODE>$(CC)</CODE> command fails (exits with a nonzero status). Normally the
|
|
shell exits with the status of the last command in the pipeline
|
|
(<CODE>sed</CODE> in this case), so <CODE>make</CODE> would not notice a nonzero
|
|
status from the compiler.
|
|
<A NAME="IDX260"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX261"></A>
|
|
With the GNU C compiler, you may wish to use the <SAMP>`-MM'</SAMP> flag instead
|
|
of <SAMP>`-M'</SAMP>. This omits prerequisites on system header files.
|
|
See section `Options Controlling the Preprocessor' in <CITE>Using GNU CC</CITE>, for details.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX262"></A>
|
|
The purpose of the <CODE>sed</CODE> command is to translate (for example):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
main.o : main.c defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
into:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
main.o main.d : main.c defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX263"></A>
|
|
This makes each <SAMP>`.d'</SAMP> file depend on all the source and header files
|
|
that the corresponding <SAMP>`.o'</SAMP> file depends on. <CODE>make</CODE> then
|
|
knows it must regenerate the prerequisites whenever any of the source or
|
|
header files changes.
|
|
|
|
</P>
|
|
<P>
|
|
Once you've defined the rule to remake the <SAMP>`.d'</SAMP> files,
|
|
you then use the <CODE>include</CODE> directive to read them all in.
|
|
See section <A HREF="make_3.html#SEC15">Including Other Makefiles</A>. For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
sources = foo.c bar.c
|
|
|
|
include $(sources:.c=.d)
|
|
</PRE>
|
|
|
|
<P>
|
|
(This example uses a substitution variable reference to translate the
|
|
list of source files <SAMP>`foo.c bar.c'</SAMP> into a list of prerequisite
|
|
makefiles, <SAMP>`foo.d bar.d'</SAMP>. See section <A HREF="make_6.html#SEC61">Substitution References</A>, for full
|
|
information on substitution references.) Since the <SAMP>`.d'</SAMP> files are
|
|
makefiles like any others, <CODE>make</CODE> will remake them as necessary
|
|
with no further work from you. See section <A HREF="make_3.html#SEC17">How Makefiles Are Remade</A>.
|
|
|
|
</P>
|
|
<P><HR><P>
|
|
<p>Go to the <A HREF="make_1.html">first</A>, <A HREF="make_3.html">previous</A>, <A HREF="make_5.html">next</A>, <A HREF="make_19.html">last</A> section, <A HREF="make_toc.html">table of contents</A>.
|
|
</BODY>
|
|
</HTML>
|