The variable-assignment can be any valid form of assignment; recursive (`='), static (`:='), appending (`+='), or conditional (`?='). All variables that appear within the variable-assignment are evaluated within the context of the target: thus, any previously-defined target-specific variable values will be in effect. Note that this variable is actually distinct from any "global" value: the two variables do not have to have the same flavor (recursive vs. static).
Target-specific variables have the same priority as any other makefile
variable. Variables provided on the command-line (and in the
environment if the `-e' option is in force) will take precedence.
Specifying the override
directive will allow the target-specific
variable value to be preferred.
There is one more special feature of target-specific variables: when you define a target-specific variable, that variable value is also in effect for all prerequisites of this target (unless those prerequisites override it with their own target-specific variable value). So, for example, a statement like this:
prog : CFLAGS = -g prog : prog.o foo.o bar.o
will set CFLAGS
to `-g' in the command script for
`prog', but it will also set CFLAGS
to `-g' in the
command scripts that create `prog.o', `foo.o', and
`bar.o', and any command scripts which create their prerequisites.
In addition to target-specific variable values (see section Target-specific Variable Values), GNU make
supports
pattern-specific variable values. In this form, a variable is defined
for any target that matches the pattern specified. Variables defined in
this way are searched after any target-specific variables defined
explicitly for that target, and before target-specific variables defined
for the parent target.
Set a pattern-specific variable value like this:
pattern ... : variable-assignment
or like this:
pattern ... : override variable-assignment
where pattern is a %-pattern. As with target-specific variable
values, multiple pattern values create a pattern-specific variable
value for each pattern individually. The variable-assignment can
be any valid form of assignment. Any command-line variable setting will
take precedence, unless override
is specified.
For example:
%.o : CFLAGS = -O
will assign CFLAGS
the value of `-O' for all targets
matching the pattern %.o
.
A conditional causes part of a makefile to be obeyed or ignored
depending on the values of variables. Conditionals can compare the
value of one variable to another, or the value of a variable to
a constant string. Conditionals control what make
actually
"sees" in the makefile, so they cannot be used to control shell
commands at the time of execution.
The following example of a conditional tells make
to use one set
of libraries if the CC
variable is `gcc', and a different
set of libraries otherwise. It works by controlling which of two
command lines will be used as the command for a rule. The result is
that `CC=gcc' as an argument to make
changes not only which
compiler is used but also which libraries are linked.
libs_for_gcc = -lgnu normal_libs = foo: $(objects) ifeq ($(CC),gcc) $(CC) -o foo $(objects) $(libs_for_gcc) else $(CC) -o foo $(objects) $(normal_libs) endif
This conditional uses three directives: one ifeq
, one else
and one endif
.
The ifeq
directive begins the conditional, and specifies the
condition. It contains two arguments, separated by a comma and surrounded
by parentheses. Variable substitution is performed on both arguments and
then they are compared. The lines of the makefile following the
ifeq
are obeyed if the two arguments match; otherwise they are
ignored.
The else
directive causes the following lines to be obeyed if the
previous conditional failed. In the example above, this means that the
second alternative linking command is used whenever the first alternative
is not used. It is optional to have an else
in a conditional.
The endif
directive ends the conditional. Every conditional must
end with an endif
. Unconditional makefile text follows.
As this example illustrates, conditionals work at the textual level: the lines of the conditional are treated as part of the makefile, or ignored, according to the condition. This is why the larger syntactic units of the makefile, such as rules, may cross the beginning or the end of the conditional.
When the variable CC
has the value `gcc', the above example has
this effect:
foo: $(objects) $(CC) -o foo $(objects) $(libs_for_gcc)
When the variable CC
has any other value, the effect is this:
foo: $(objects) $(CC) -o foo $(objects) $(normal_libs)
Equivalent results can be obtained in another way by conditionalizing a variable assignment and then using the variable unconditionally:
libs_for_gcc = -lgnu normal_libs = ifeq ($(CC),gcc) libs=$(libs_for_gcc) else libs=$(normal_libs) endif foo: $(objects) $(CC) -o foo $(objects) $(libs)
The syntax of a simple conditional with no else
is as follows:
conditional-directive text-if-true endif
The text-if-true may be any lines of text, to be considered as part of the makefile if the condition is true. If the condition is false, no text is used instead.
The syntax of a complex conditional is as follows:
conditional-directive text-if-true else text-if-false endif
If the condition is true, text-if-true is used; otherwise, text-if-false is used instead. The text-if-false can be any number of lines of text.
The syntax of the conditional-directive is the same whether the conditional is simple or complex. There are four different directives that test different conditions. Here is a table of them:
ifeq (arg1, arg2)
ifeq 'arg1' 'arg2'
ifeq "arg1" "arg2"
ifeq "arg1" 'arg2'
ifeq 'arg1' "arg2"
strip
function (see section Functions for String Substitution and Analysis) to avoid interpreting
whitespace as a non-empty value. For example:
ifeq ($(strip $(foo)),) text-if-empty endifwill evaluate text-if-empty even if the expansion of
$(foo)
contains whitespace characters.
ifneq (arg1, arg2)
ifneq 'arg1' 'arg2'
ifneq "arg1" "arg2"
ifneq "arg1" 'arg2'
ifneq 'arg1' "arg2"
ifdef variable-name
ifdef
only tests whether a variable has a value. It
does not expand the variable to see if that value is nonempty.
Consequently, tests using ifdef
return true for all definitions
except those like foo =
. To test for an empty value, use
ifeq ($(foo),)
. For example,
bar = foo = $(bar) ifdef foo frobozz = yes else frobozz = no endifsets `frobozz' to `yes', while:
foo = ifdef foo frobozz = yes else frobozz = no endifsets `frobozz' to `no'.
ifndef variable-name
Extra spaces are allowed and ignored at the beginning of the conditional directive line, but a tab is not allowed. (If the line begins with a tab, it will be considered a command for a rule.) Aside from this, extra spaces or tabs may be inserted with no effect anywhere except within the directive name or within an argument. A comment starting with `#' may appear at the end of the line.
The other two directives that play a part in a conditional are else
and endif
. Each of these directives is written as one word, with no
arguments. Extra spaces are allowed and ignored at the beginning of the
line, and spaces or tabs at the end. A comment starting with `#' may
appear at the end of the line.
Conditionals affect which lines of the makefile make
uses. If
the condition is true, make
reads the lines of the
text-if-true as part of the makefile; if the condition is false,
make
ignores those lines completely. It follows that syntactic
units of the makefile, such as rules, may safely be split across the
beginning or the end of the conditional.
make
evaluates conditionals when it reads a makefile.
Consequently, you cannot use automatic variables in the tests of
conditionals because they are not defined until commands are run
(see section Automatic Variables).
To prevent intolerable confusion, it is not permitted to start a
conditional in one makefile and end it in another. However, you may
write an include
directive within a conditional, provided you do
not attempt to terminate the conditional inside the included file.
You can write a conditional that tests make
command flags such as
`-t' by using the variable MAKEFLAGS
together with the
findstring
function
(see section Functions for String Substitution and Analysis).
This is useful when touch
is not enough to make a file appear up
to date.
The findstring
function determines whether one string appears as a
substring of another. If you want to test for the `-t' flag,
use `t' as the first string and the value of MAKEFLAGS
as
the other.
For example, here is how to arrange to use `ranlib -t' to finish marking an archive file up to date:
archive.a: ... ifneq (,$(findstring t,$(MAKEFLAGS))) +touch archive.a +ranlib -t archive.a else ranlib archive.a endif
The `+' prefix marks those command lines as "recursive" so
that they will be executed despite use of the `-t' flag.
See section Recursive Use of make
.
Functions allow you to do text processing in the makefile to compute the files to operate on or the commands to use. You use a function in a function call, where you give the name of the function and some text (the arguments) for the function to operate on. The result of the function's processing is substituted into the makefile at the point of the call, just as a variable might be substituted.
A function call resembles a variable reference. It looks like this:
$(function arguments)
or like this:
${function arguments}
Here function is a function name; one of a short list of names
that are part of make
. You can also essentially create your own
functions by using the call
builtin function.
The arguments are the arguments of the function. They are separated from the function name by one or more spaces or tabs, and if there is more than one argument, then they are separated by commas. Such whitespace and commas are not part of an argument's value. The delimiters which you use to surround the function call, whether parentheses or braces, can appear in an argument only in matching pairs; the other kind of delimiters may appear singly. If the arguments themselves contain other function calls or variable references, it is wisest to use the same kind of delimiters for all the references; write `$(subst a,b,$(x))', not `$(subst a,b,${x})'. This is because it is clearer, and because only one type of delimiter is matched to find the end of the reference.
The text written for each argument is processed by substitution of variables and function calls to produce the argument value, which is the text on which the function acts. The substitution is done in the order in which the arguments appear.
Commas and unmatched parentheses or braces cannot appear in the text of an
argument as written; leading spaces cannot appear in the text of the first
argument as written. These characters can be put into the argument value
by variable substitution. First define variables comma
and
space
whose values are isolated comma and space characters, then
substitute these variables where such characters are wanted, like this:
comma:= , empty:= space:= $(empty) $(empty) foo:= a b c bar:= $(subst $(space),$(comma),$(foo)) # bar is now `a,b,c'.
Here the subst
function replaces each space with a comma, through
the value of foo
, and substitutes the result.
Here are some functions that operate on strings:
$(subst from,to,text)
$(subst ee,EE,feet on the street)substitutes the string `fEEt on the strEEt'.
$(patsubst pattern,replacement,text)
patsubst
function invocations 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 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.
Whitespace between words is folded into single space characters;
leading and trailing whitespace is discarded.
For example,
$(patsubst %.c,%.o,x.c.c bar.c)produces the value `x.c.o bar.o'. Substitution references (see section Substitution References) are a simpler way to get the effect of the
patsubst
function:
$(var:pattern=replacement)is equivalent to
$(patsubst pattern,replacement,$(var))The second shorthand simplifies one of the most common uses of
patsubst
: replacing the suffix at the end of file names.
$(var:suffix=replacement)is equivalent to
$(patsubst %suffix,%replacement,$(var))For example, you might have a list of object files:
objects = foo.o bar.o baz.oTo get the list of corresponding source files, you could simply write:
$(objects:.o=.c)instead of using the general form:
$(patsubst %.o,%.c,$(objects))
$(strip string)
strip
can be very useful when used in conjunction
with conditionals. When comparing something with the empty string
`' using ifeq
or ifneq
, you usually want a string of
just whitespace to match the empty string (see section Conditional Parts of Makefiles).
Thus, the following may fail to have the desired results:
.PHONY: all ifneq "$(needs_made)" "" all: $(needs_made) else all:;@echo 'Nothing to make!' endifReplacing the variable reference `$(needs_made)' with the function call `$(strip $(needs_made))' in the
ifneq
directive would make it more robust.
$(findstring find,in)
$(findstring a,a b c) $(findstring a,b c)produce the values `a' and `' (the empty string), respectively. See section Conditionals that Test Flags, for a practical application of
findstring
.
$(filter pattern...,text)
patsubst
function above.
The filter
function can be used to separate out different types
of strings (such as file names) in a variable. For example:
sources := foo.c bar.c baz.s ugh.h foo: $(sources) cc $(filter %.c %.s,$(sources)) -o foosays that `foo' depends of `foo.c', `bar.c', `baz.s' and `ugh.h' but only `foo.c', `bar.c' and `baz.s' should be specified in the command to the compiler.
$(filter-out pattern...,text)
filter
function.
Removes all whitespace-separated words in text that do
match the pattern words, returning only the words that do
not match. This is the exact opposite of the filter
function.
For example, given:
objects=main1.o foo.o main2.o bar.o mains=main1.o main2.othe following generates a list which contains all the object files not in `mains':
$(filter-out $(mains),$(objects))
$(sort list)
$(sort foo bar lose)returns the value `bar foo lose'. Incidentally, since
sort
removes duplicate words, you can use
it for this purpose even if you don't care about the sort order.
Here is a realistic example of the use of subst
and
patsubst
. Suppose that a makefile uses the VPATH
variable
to specify a list of directories that make
should search for
prerequisite files
(see section VPATH
: Search Path for All Prerequisites).
This example shows how to
tell the C compiler to search for header files in the same list of
directories.
The value of VPATH
is a list of directories separated by colons,
such as `src:../headers'. First, the subst
function is used to
change the colons to spaces:
$(subst :, ,$(VPATH))
This produces `src ../headers'. Then patsubst
is used to turn
each directory name into a `-I' flag. These can be added to the
value of the variable CFLAGS
, which is passed automatically to the C
compiler, like this:
override CFLAGS += $(patsubst %,-I%,$(subst :, ,$(VPATH)))
The effect is to append the text `-Isrc -I../headers' to the
previously given value of CFLAGS
. The override
directive is
used so that the new value is assigned even if the previous value of
CFLAGS
was specified with a command argument (see section The override
Directive).
Several of the built-in expansion functions relate specifically to taking apart file names or lists of file names.
Each of the following functions performs a specific transformation on a file name. The argument of the function is regarded as a series of file names, separated by whitespace. (Leading and trailing whitespace is ignored.) Each file name in the series is transformed in the same way and the results are concatenated with single spaces between them.
$(dir names...)
$(dir src/foo.c hacks)produces the result `src/ ./'.
$(notdir names...)
$(notdir src/foo.c hacks)produces the result `foo.c hacks'.
$(suffix names...)
$(suffix src/foo.c src-1.0/bar.c hacks)produces the result `.c .c'.
$(basename names...)
$(basename src/foo.c src-1.0/bar hacks)produces the result `src/foo src-1.0/bar hacks'.
$(addsuffix suffix,names...)
$(addsuffix .c,foo bar)produces the result `foo.c bar.c'.
$(addprefix prefix,names...)
$(addprefix src/,foo bar)produces the result `src/foo src/bar'.
$(join list1,list2)
dir
and
notdir
functions, to produce the original list of files which
was given to those two functions.
$(word n,text)
$(word 2, foo bar baz)returns `bar'.
$(wordlist s,e,text)
$(wordlist 2, 3, foo bar baz)returns `bar baz'.
$(words text)
$(word $(words text),text)
.
$(firstword names...)
$(firstword foo bar)produces the result `foo'. Although
$(firstword
text)
is the same as $(word 1,text)
, the
firstword
function is retained for its simplicity.
$(wildcard pattern)
wildcard
is a space-separated list of the names of existing files
that match the pattern.
See section Using Wildcard Characters in File Names.
foreach
Function
The foreach
function is very different from other functions. It
causes one piece of text to be used repeatedly, each time with a different
substitution performed on it. It resembles the for
command in the
shell sh
and the foreach
command in the C-shell csh
.
The syntax of the foreach
function is:
$(foreach var,list,text)
The first two arguments, var and list, are expanded before anything else is done; note that the last argument, text, is not expanded at the same time. Then for each word of the expanded value of list, the variable named by the expanded value of var is set to that word, and text is expanded. Presumably text contains references to that variable, so its expansion will be different each time.
The result is that text is expanded as many times as there are
whitespace-separated words in list. The multiple expansions of
text are concatenated, with spaces between them, to make the result
of foreach
.
This simple example sets the variable `files' to the list of all files in the directories in the list `dirs':
dirs := a b c d files := $(foreach dir,$(dirs),$(wildcard $(dir)/*))
Here text is `$(wildcard $(dir)/*)'. The first repetition
finds the value `a' for dir
, so it produces the same result
as `$(wildcard a/*)'; the second repetition produces the result
of `$(wildcard b/*)'; and the third, that of `$(wildcard c/*)'.
This example has the same result (except for setting `dirs') as the following example:
files := $(wildcard a/* b/* c/* d/*)
When text is complicated, you can improve readability by giving it a name, with an additional variable:
find_files = $(wildcard $(dir)/*) dirs := a b c d files := $(foreach dir,$(dirs),$(find_files))
Here we use the variable find_files
this way. We use plain `='
to define a recursively-expanding variable, so that its value contains an
actual function call to be reexpanded under the control of foreach
;
a simply-expanded variable would not do, since wildcard
would be
called only once at the time of defining find_files
.
The foreach
function has no permanent effect on the variable
var; its value and flavor after the foreach
function call are
the same as they were beforehand. The other values which are taken from
list are in effect only temporarily, during the execution of
foreach
. The variable var is a simply-expanded variable
during the execution of foreach
. If var was undefined
before the foreach
function call, it is undefined after the call.
See section The Two Flavors of Variables.
You must take care when using complex variable expressions that result in variable names because many strange things are valid variable names, but are probably not what you intended. For example,
files := $(foreach Esta escrito en espanol!,b c ch,$(find_files))
might be useful if the value of find_files
references the variable
whose name is `Esta escrito en espanol!' (es un nombre bastante largo,
no?), but it is more likely to be a mistake.
if
Function
The if
function provides support for conditional expansion in a
functional context (as opposed to the GNU make
makefile
conditionals such as ifeq
(see section Syntax of Conditionals).
An if
function call can contain either two or three arguments:
$(if condition,then-part[,else-part])
The first argument, condition, first has all preceding and trailing whitespace stripped, then is expanded. If it expands to any non-empty string, then the condition is considered to be true. If it expands to an empty string, the condition is considered to be false.
If the condition is true then the second argument, then-part, is
evaluated and this is used as the result of the evaluation of the entire
if
function.
If the condition is false then the third argument, else-part, is
evaluated and this is the result of the if
function. If there is
no third argument, the if
function evaluates to nothing (the
empty string).
Note that only one of the then-part or the else-part will be
evaluated, never both. Thus, either can contain side-effects (such as
shell
function calls, etc.)
call
Function
The call
function is unique in that it can be used to create new
parameterized functions. You can write a complex expression as the
value of a variable, then use call
to expand it with different
values.
The syntax of the call
function is:
$(call variable,param,param,...)
When make
expands this function, it assigns each param to
temporary variables $(1)
, $(2)
, etc. The variable
$(0)
will contain variable. There is no maximum number of
parameter arguments. There is no minimum, either, but it doesn't make
sense to use call
with no parameters.
Then variable is expanded as a make
variable in the context
of these temporary assignments. Thus, any reference to $(1)
in
the value of variable will resolve to the first param in the
invocation of call
.
Note that variable is the name of a variable, not a reference to that variable. Therefore you would not normally use a `$' or parentheses when writing it. (You can, however, use a variable reference in the name if you want the name not to be a constant.)
If variable is the name of a builtin function, the builtin function
is always invoked (even if a make
variable by that name also
exists).
The call
function expands the param arguments before
assigning them to temporary variables. This means that variable
values containing references to builtin functions that have special
expansion rules, like foreach
or if
, may not work as you
expect.
Some examples may make this clearer.
This macro simply reverses its arguments:
reverse = $(2) $(1) foo = $(call reverse,a,b)
Here foo will contain `b a'.
This one is slightly more interesting: it defines a macro to search for
the first instance of a program in PATH
:
pathsearch = $(firstword $(wildcard $(addsufix /$(1),$(subst :, ,$(PATH))))) LS := $(call pathsearch,ls)
Now the variable LS contains /bin/ls
or similar.
The call
function can be nested. Each recursive invocation gets
its own local values for $(1)
, etc. that mask the values of
higher-level call
. For example, here is an implementation of a
map function:
map = $(foreach a,$(2),$(call $(1),$(a)))
Now you can map a function that normally takes only one argument,
such as origin
, to multiple values in one step:
o = $(call map,origin,o map MAKE)
and end up with o containing something like `file file default'.
A final caution: be careful when adding whitespace to the arguments to
call
. As with other functions, any whitespace contained in the
second and subsequent arguments is kept; this can cause strange
effects. It's generally safest to remove all extraneous whitespace when
providing parameters to call
.
origin
Function
The origin
function is unlike most other functions in that it does
not operate on the values of variables; it tells you something about
a variable. Specifically, it tells you where it came from.
The syntax of the origin
function is:
$(origin variable)
Note that variable is the name of a variable to inquire about; not a reference to that variable. Therefore you would not normally use a `$' or parentheses when writing it. (You can, however, use a variable reference in the name if you want the name not to be a constant.)
The result of this function is a string telling you how the variable variable was defined:
CC
and so on. See section Variables Used by Implicit Rules.
Note that if you have redefined a default variable, the origin
function will return the origin of the later definition.
override
directive in a
makefile (see section The override
Directive).
This information is primarily useful (other than for your curiosity) to
determine if you want to believe the value of a variable. For example,
suppose you have a makefile `foo' that includes another makefile
`bar'. You want a variable bletch
to be defined in `bar'
if you run the command `make -f bar', even if the environment contains
a definition of bletch
. However, if `foo' defined
bletch
before including `bar', you do not want to override that
definition. This could be done by using an override
directive in
`foo', giving that definition precedence over the later definition in
`bar'; unfortunately, the override
directive would also
override any command line definitions. So, `bar' could
include:
ifdef bletch ifeq "$(origin bletch)" "environment" bletch = barf, gag, etc. endif endif
If bletch
has been defined from the environment, this will redefine
it.
If you want to override a previous definition of bletch
if it came
from the environment, even under `-e', you could instead write:
ifneq "$(findstring environment,$(origin bletch))" "" bletch = barf, gag, etc. endif
Here the redefinition takes place if `$(origin bletch)' returns either `environment' or `environment override'. See section Functions for String Substitution and Analysis.
shell
Function
The shell
function is unlike any other function except the
wildcard
function
(see section The Function wildcard
) in that it
communicates with the world outside of make
.
The shell
function performs the same function that backquotes
(``') perform in most shells: it does command expansion. This
means that it takes an argument that is a shell command and returns the
output of the command. The only processing make
does on the result,
before substituting it into the surrounding text, is to convert each
newline or carriage-return / newline pair to a single space. It also
removes the trailing (carriage-return and) newline, if it's the last
thing in the result.
The commands run by calls to the shell
function are run when the
function calls are expanded. In most cases, this is when the makefile is
read in. The exception is that function calls in the commands of the rules
are expanded when the commands are run, and this applies to shell
function calls like all others.
Here are some examples of the use of the shell
function:
contents := $(shell cat foo)
sets contents
to the contents of the file `foo', with a space
(rather than a newline) separating each line.
files := $(shell echo *.c)
sets files
to the expansion of `*.c'. Unless make
is
using a very strange shell, this has the same result as
`$(wildcard *.c)'.
These functions control the way make runs. Generally, they are used to provide information to the user of the makefile or to cause make to stop if some sort of environmental error is detected.
$(error text...)
ifdef ERROR1 $(error error is $(ERROR1)) endifwill generate a fatal error during the read of the makefile if the
make
variable ERROR1
is defined. Or,
ERR = $(error found an error!) .PHONY: err err: ; $(ERR)will generate a fatal error while
make
is running, if the
err
target is invoked.
$(warning text...)
error
function, above,
except that make
doesn't exit. Instead, text is expanded
and the resulting message is displayed, but processing of the makefile
continues.
The result of the expansion of this function is the empty string.
make
A makefile that says how to recompile a program can be used in more
than one way. The simplest use is to recompile every file that is out
of date. Usually, makefiles are written so that if you run
make
with no arguments, it does just that.
But you might want to update only some of the files; you might want to use a different compiler or different compiler options; you might want just to find out which files are out of date without changing them.
By giving arguments when you run make
, you can do any of these
things and many others.
The exit status of make
is always one of three values:
0
make
is successful.
2
make
encounters any errors.
It will print messages describing the particular errors.
1
make
determines that some target is not already up to date.
See section Instead of Executing the Commands.
The way to specify the name of the makefile is with the `-f' or `--file' option (`--makefile' also works). For example, `-f altmake' says to use the file `altmake' as the makefile.
If you use the `-f' flag several times and follow each `-f' with an argument, all the specified files are used jointly as makefiles.
If you do not use the `-f' or `--file' flag, the default is to try `GNUmakefile', `makefile', and `Makefile', in that order, and use the first of these three which exists or can be made (see section Writing Makefiles).
The goals are the targets that make
should strive ultimately
to update. Other targets are updated as well if they appear as
prerequisites of goals, or prerequisites of prerequisites of goals, etc.
By default, the goal is the first target in the makefile (not counting targets that start with a period). Therefore, makefiles are usually written so that the first target is for compiling the entire program or programs they describe. If the first rule in the makefile has several targets, only the first target in the rule becomes the default goal, not the whole list.
You can specify a different goal or goals with arguments to make
.
Use the name of the goal as an argument. If you specify several goals,
make
processes each of them in turn, in the order you name them.
Any target in the makefile may be specified as a goal (unless it
starts with `-' or contains an `=', in which case it will be
parsed as a switch or variable definition, respectively). Even
targets not in the makefile may be specified, if make
can find
implicit rules that say how to make them.
Make
will set the special variable MAKECMDGOALS
to the
list of goals you specified on the command line. If no goals were given
on the command line, this variable is empty. Note that this variable
should be used only in special circumstances.
An example of appropriate use is to avoid including `.d' files
during clean
rules (see section Generating Prerequisites Automatically), so
make
won't create them only to immediately remove them
again:
sources = foo.c bar.c ifneq ($(MAKECMDGOALS),clean) include $(sources:.c=.d) endif
One use of specifying a goal is if you want to compile only a part of the program, or only one of several programs. Specify as a goal each file that you wish to remake. For example, consider a directory containing several programs, with a makefile that starts like this:
.PHONY: all all: size nm ld ar as
If you are working on the program size
, you might want to say
`make size' so that only the files of that program are recompiled.
Another use of specifying a goal is to make files that are not normally made. For example, there may be a file of debugging output, or a version of the program that is compiled specially for testing, which has a rule in the makefile but is not a prerequisite of the default goal.
Another use of specifying a goal is to run the commands associated with a phony target (see section Phony Targets) or empty target (see section Empty Target Files to Record Events). Many makefiles contain a phony target named `clean' which deletes everything except source files. Naturally, this is done only if you request it explicitly with `make clean'. Following is a list of typical phony and empty target names. See section Standard Targets for Users, for a detailed list of all the standard target names which GNU software packages use.
make
.
The makefile tells make
how to tell whether a target is up to date,
and how to update each target. But updating the targets is not always
what you want. Certain options specify other activities for make
.
make
pretends to compile
the targets but does not really change their contents.
make
as being the present
time, although the actual modification times remain the same.
You can use the `-W' flag in conjunction with the `-n' flag
to see what would happen if you were to modify specific files.
With the `-n' flag, make
prints the commands that it would
normally execute but does not execute them.
With the `-t' flag, make
ignores the commands in the rules
and uses (in effect) the command touch
for each target that needs to
be remade. The touch
command is also printed, unless `-s' or
.SILENT
is used. For speed, make
does not actually invoke
the program touch
. It does the work directly.
With the `-q' flag, make
prints nothing and executes no
commands, but the exit status code it returns is zero if and only if the
targets to be considered are already up to date. If the exit status is
one, then some updating needs to be done. If make
encounters an
error, the exit status is two, so you can distinguish an error from a
target that is not up to date.
It is an error to use more than one of these three flags in the same
invocation of make
.
The `-n', `-t', and `-q' options do not affect command
lines that begin with `+' characters or contain the strings
`$(MAKE)' or `${MAKE}'. Note that only the line containing
the `+' character or the strings `$(MAKE)' or `${MAKE}'
is run regardless of these options. Other lines in the same rule are
not run unless they too begin with `+' or contain `$(MAKE)' or
`${MAKE}' (See section How the MAKE
Variable Works.)
The `-W' flag provides two features:
make
would do if you were to modify some files.
make
is actually
executing commands, the `-W' flag can direct make
to act
as if some files had been modified, without actually modifying the
files.
Note that the options `-p' and `-v' allow you to obtain other
information about make
or about the makefiles in use
(see section Summary of Options).
Sometimes you may have changed a source file but you do not want to
recompile all the files that depend on it. For example, suppose you add
a macro or a declaration to a header file that many other files depend
on. Being conservative, make
assumes that any change in the
header file requires recompilation of all dependent files, but you know
that they do not need to be recompiled and you would rather not waste
the time waiting for them to compile.
If you anticipate the problem before changing the header file, you can
use the `-t' flag. This flag tells make
not to run the
commands in the rules, but rather to mark the target up to date by
changing its last-modification date. You would follow this procedure:
make
, the changes in the
header files will not cause any recompilation.
If you have already changed the header file at a time when some files do need recompilation, it is too late to do this. Instead, you can use the `-o file' flag, which marks a specified file as "old" (see section Summary of Options). This means that the file itself will not be remade, and nothing else will be remade on its account. Follow this procedure:
An argument that contains `=' specifies the value of a variable: `v=x' sets the value of the variable v to x. If you specify a value in this way, all ordinary assignments of the same variable in the makefile are ignored; we say they have been overridden by the command line argument.
The most common way to use this facility is to pass extra flags to
compilers. For example, in a properly written makefile, the variable
CFLAGS
is included in each command that runs the C compiler, so a
file `foo.c' would be compiled something like this:
cc -c $(CFLAGS) foo.c
Thus, whatever value you set for CFLAGS
affects each compilation
that occurs. The makefile probably specifies the usual value for
CFLAGS
, like this:
CFLAGS=-g
Each time you run make
, you can override this value if you
wish. For example, if you say `make CFLAGS='-g -O'', each C
compilation will be done with `cc -c -g -O'. (This illustrates
how you can use quoting in the shell to enclose spaces and other
special characters in the value of a variable when you override it.)
The variable CFLAGS
is only one of many standard variables that
exist just so that you can change them this way. See section Variables Used by Implicit Rules, for a complete list.
You can also program the makefile to look at additional variables of your own, giving the user the ability to control other aspects of how the makefile works by changing the variables.
When you override a variable with a command argument, you can define either a recursively-expanded variable or a simply-expanded variable. The examples shown above make a recursively-expanded variable; to make a simply-expanded variable, write `:=' instead of `='. But, unless you want to include a variable reference or function call in the value that you specify, it makes no difference which kind of variable you create.
There is one way that the makefile can change a variable that you have
overridden. This is to use the override
directive, which is a line
that looks like this: `override variable = value'
(see section The override
Directive).
Normally, when an error happens in executing a shell command, make
gives up immediately, returning a nonzero status. No further commands are
executed for any target. The error implies that the goal cannot be
correctly remade, and make
reports this as soon as it knows.
When you are compiling a program that you have just changed, this is not
what you want. Instead, you would rather that make
try compiling
every file that can be tried, to show you as many compilation errors
as possible.
On these occasions, you should use the `-k' or
`--keep-going' flag. This tells make
to continue to
consider the other prerequisites of the pending targets, remaking them
if necessary, before it gives up and returns nonzero status. For
example, after an error in compiling one object file, `make -k'
will continue compiling other object files even though it already
knows that linking them will be impossible. In addition to continuing
after failed shell commands, `make -k' will continue as much as
possible after discovering that it does not know how to make a target
or prerequisite file. This will always cause an error message, but
without `-k', it is a fatal error (see section Summary of Options).
The usual behavior of make
assumes that your purpose is to get the
goals up to date; once make
learns that this is impossible, it might
as well report the failure immediately. The `-k' flag says that the
real purpose is to test as much as possible of the changes made in the
program, perhaps to find several independent problems so that you can
correct them all before the next attempt to compile. This is why Emacs'
M-x compile command passes the `-k' flag by default.
Here is a table of all the options make
understands:
make
.
make
(see section Recursive Use of make
).
make
decides what to do. The -d
option is equivalent to
`--debug=a' (see below).
a (all)
b (basic)
v (verbose)
i (implicit)
j (jobs)
m (makefile)
make
understands and then exit.
make
runs as many jobs simultaneously as possible. If
there is more than one `-j' option, the last one is effective.
See section Parallel Execution,
for more information on how commands are run.
Note that this option is ignored on MS-DOS.
.SUFFIXES
, and then define your own suffix rules. Note that only
rules are affected by the -r
option; default variables
remain in effect (see section Variables Used by Implicit Rules); see the `-R' option below.
make
where `-k' might be inherited
from the top-level make
via MAKEFLAGS
(see section Recursive Use of make
)
or if you set `-k' in MAKEFLAGS
in your environment.
make
. See section Instead of Executing the Commands.
make
program plus a copyright, a list
of authors, and a notice that there is no warranty; then exit.
make
commands.
See section Recursive Use of make
. (In practice, you
rarely need to specify this option since `make' does it for you;
see section The `--print-directory' Option.)
-w
.
This option is useful when -w
is turned on automatically,
but you do not want to see the extra messages.
See section The `--print-directory' Option.
touch
command on the given file before running
make
, except that the modification time is changed only in the
imagination of make
.
See section Instead of Executing the Commands.
make
sees a reference to an
undefined variable. This can be helpful when you are trying to debug
makefiles which use variables in complex ways.
Certain standard ways of remaking target files are used very often. For
example, one customary way to make an object file is from a C source file
using the C compiler, cc
.
Implicit rules tell make
how to use customary techniques so
that you do not have to specify them in detail when you want to use
them. For example, there is an implicit rule for C compilation. File
names determine which implicit rules are run. For example, C
compilation typically takes a `.c' file and makes a `.o' file.
So make
applies the implicit rule for C compilation when it sees
this combination of file name endings.
A chain of implicit rules can apply in sequence; for example, make
will remake a `.o' file from a `.y' file by way of a `.c' file.
See section Chains of Implicit Rules.
The built-in implicit rules use several variables in their commands so
that, by changing the values of the variables, you can change the way the
implicit rule works. For example, the variable CFLAGS
controls the
flags given to the C compiler by the implicit rule for C compilation.
See section Variables Used by Implicit Rules.
You can define your own implicit rules by writing pattern rules. See section Defining and Redefining Pattern Rules.
Suffix rules are a more limited way to define implicit rules. Pattern rules are more general and clearer, but suffix rules are retained for compatibility. See section Old-Fashioned Suffix Rules.
To allow make
to find a customary method for updating a target file,
all you have to do is refrain from specifying commands yourself.  Then
make
will figure out which implicit rule to use based on which
kind of source file exists or can be made.
For example, suppose the makefile looks like this:
foo : foo.o bar.o cc -o foo foo.o bar.o $(CFLAGS) $(LDFLAGS)
Because you mention `foo.o' but do not give a rule for it, make
will automatically look for an implicit rule that tells how to update it.
This happens whether or not the file `foo.o' currently exists.
If an implicit rule is found, it can supply both commands and one or more prerequisites (the source files). You would want to write a rule for `foo.o' with no command lines if you need to specify additional prerequisites, such as header files, that the implicit rule cannot supply.
Each implicit rule has a target pattern and prerequisite patterns. There may
be many implicit rules with the same target pattern. For example, numerous
rules make `.o' files: one, from a `.c' file with the C compiler;
another, from a `.p' file with the Pascal compiler; and so on. The rule
that actually applies is the one whose prerequisites exist or can be made.
So, if you have a file `foo.c', make
will run the C compiler;
otherwise, if you have a file `foo.p', make
will run the Pascal
compiler; and so on.
Of course, when you write the makefile, you know which implicit rule you
want make
to use, and you know it will choose that one because you
know which possible prerequisite files are supposed to exist.
See section Catalogue of Implicit Rules,
for a catalogue of all the predefined implicit rules.
Above, we said an implicit rule applies if the required prerequisites "exist or can be made". A file "can be made" if it is mentioned explicitly in the makefile as a target or a prerequisite, or if an implicit rule can be recursively found for how to make it. When an implicit prerequisite is the result of another implicit rule, we say that chaining is occurring. See section Chains of Implicit Rules.
In general, make
searches for an implicit rule for each target, and
for each double-colon rule, that has no commands. A file that is mentioned
only as a prerequisite is considered a target whose rule specifies nothing,
so implicit rule search happens for it. See section Implicit Rule Search Algorithm, for the
details of how the search is done.
Note that explicit prerequisites do not influence implicit rule search. For example, consider this explicit rule:
foo.o: foo.p
The prerequisite on `foo.p' does not necessarily mean that
make
will remake `foo.o' according to the implicit rule to
make an object file, a `.o' file, from a Pascal source file, a
`.p' file. For example, if `foo.c' also exists, the implicit
rule to make an object file from a C source file is used instead,
because it appears before the Pascal rule in the list of predefined
implicit rules (see section Catalogue of Implicit Rules).
If you do not want an implicit rule to be used for a target that has no commands, you can give that target empty commands by writing a semicolon (see section Using Empty Commands).
Here is a catalogue of predefined implicit rules which are always available unless the makefile explicitly overrides or cancels them. See section Canceling Implicit Rules, for information on canceling or overriding an implicit rule. The `-r' or `--no-builtin-rules' option cancels all predefined rules.
Not all of these rules will always be defined, even when the `-r'
option is not given. Many of the predefined implicit rules are
implemented in make
as suffix rules, so which ones will be
defined depends on the suffix list (the list of prerequisites of
the special target .SUFFIXES
). The default suffix list is:
.out
, .a
, .ln
, .o
, .c
, .cc
,
.C
, .p
, .f
, .F
, .r
, .y
,
.l
, .s
, .S
, .mod
, .sym
, .def
,
.h
, .info
, .dvi
, .tex
, .texinfo
,
.texi
, .txinfo
, .w
, .ch
.web
,
.sh
, .elc
, .el
. All of the implicit rules
described below whose prerequisites have one of these suffixes are
actually suffix rules. If you modify the suffix list, the only
predefined suffix rules in effect will be those named by one or two of
the suffixes that are on the list you specify; rules whose suffixes fail
to be on the list are disabled. See section Old-Fashioned Suffix Rules, for full details on suffix rules.
as
. The precise command is
`$(AS) $(ASFLAGS)'.
`n.s' is made automatically from `n.S' by
running the C preprocessor, cpp
. The precise command is
`$(CPP) $(CPPFLAGS)'.
ld
) via the C compiler. The precise
command used is `$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)'.
This rule does the right thing for a simple program with only one
source file. It will also do the right thing if there are multiple
object files (presumably coming from various other source files), one
of which has a name matching that of the executable file. Thus,
x: y.o z.owhen `x.c', `y.c' and `z.c' all exist will execute:
cc -c x.c -o x.o cc -c y.c -o y.o cc -c z.c -o z.o cc x.o y.o z.o -o x rm -f x.o rm -f y.o rm -f z.oIn more complicated cases, such as when there is no object file whose name derives from the executable file name, you must write an explicit command for linking. Each kind of file automatically made into `.o' object files will be automatically linked by using the compiler (`$(CC)', `$(FC)' or `$(PC)'; the C compiler `$(CC)' is used to assemble `.s' files) without the `-c' option. This could be done by using the `.o' object files as intermediates, but it is faster to do the compiling and linking in one step, so that's how it's done.
make
to determine automatically which of the two
languages you are using in any particular case. If make
is
called upon to remake an object file from a `.l' file, it must
guess which compiler to use. It will guess the C compiler, because
that is more common. If you are using Ratfor, make sure make
knows this by mentioning `n.r' in the makefile. Or, if you
are using Ratfor exclusively, with no C files, remove `.c' from
the list of implicit rule suffixes with:
.SUFFIXES: .SUFFIXES: .o .r .f .l ...
lint
.
The precise command is `$(LINT) $(LINTFLAGS) $(CPPFLAGS) -i'.
The same command is used on the C code produced from
`n.y' or `n.l'.
Usually, you want to change only the variables listed in the table above, which are documented in the following section.
However, the commands in built-in implicit rules actually use
variables such as COMPILE.c
, LINK.p
, and
PREPROCESS.S
, whose values contain the commands listed above.
make
follows the convention that the rule to compile a
`.x' source file uses the variable COMPILE.x
.
Similarly, the rule to produce an executable from a `.x'
file uses LINK.x
; and the rule to preprocess a
`.x' file uses PREPROCESS.x
.
Every rule that produces an object file uses the variable
OUTPUT_OPTION
. make
defines this variable either to
contain `-o $@', or to be empty, depending on a compile-time
option. You need the `-o' option to ensure that the output goes
into the right file when the source file is in a different directory,
as when using VPATH
(see section Searching Directories for Prerequisites). However,
compilers on some systems do not accept a `-o' switch for object
files. If you use such a system, and use VPATH
, some
compilations will put their output in the wrong place.
A possible workaround for this problem is to give OUTPUT_OPTION
the value `; mv $*.o $@'.
The commands in built-in implicit rules make liberal use of certain
predefined variables. You can alter these variables in the makefile,
with arguments to make
, or in the environment to alter how the
implicit rules work without redefining the rules themselves. You can
cancel all variables used by implicit rules with the `-R' or
`--no-builtin-variables' option.
For example, the command used to compile a C source file actually says `$(CC) -c $(CFLAGS) $(CPPFLAGS)'. The default values of the variables used are `cc' and nothing, resulting in the command `cc -c'. By redefining `CC' to `ncc', you could cause `ncc' to be used for all C compilations performed by the implicit rule. By redefining `CFLAGS' to be `-g', you could pass the `-g' option to each compilation. All implicit rules that do C compilation use `$(CC)' to get the program name for the compiler and all include `$(CFLAGS)' among the arguments given to the compiler.
The variables used in implicit rules fall into two classes: those that are
names of programs (like CC
) and those that contain arguments for the
programs (like CFLAGS
). (The "name of a program" may also contain
some command arguments, but it must start with an actual executable program
name.) If a variable value contains more than one argument, separate them
with spaces.
Here is a table of variables used as names of programs in built-in rules:
AR
AS
CC
CXX
CO
CPP
FC
GET
LEX
PC
YACC
YACCR
MAKEINFO
TEX
TEXI2DVI
WEAVE
CWEAVE
TANGLE
CTANGLE
RM
Here is a table of variables whose values are additional arguments for the programs above. The default values for all of these is the empty string, unless otherwise noted.
ARFLAGS
ASFLAGS
CFLAGS
CXXFLAGS
COFLAGS
co
program.
CPPFLAGS
FFLAGS
GFLAGS
get
program.
LDFLAGS
LFLAGS
PFLAGS
RFLAGS
YFLAGS
Sometimes a file can be made by a sequence of implicit rules. For example,
a file `n.o' could be made from `n.y' by running
first Yacc and then cc
. Such a sequence is called a chain.
If the file `n.c' exists, or is mentioned in the makefile, no
special searching is required: make
finds that the object file can
be made by C compilation from `n.c'; later on, when considering
how to make `n.c', the rule for running Yacc is
used. Ultimately both `n.c' and `n.o' are
updated.
However, even if `n.c' does not exist and is not mentioned,
make
knows how to envision it as the missing link between
`n.o' and `n.y'! In this case, `n.c' is
called an intermediate file. Once make
has decided to use the
intermediate file, it is entered in the data base as if it had been
mentioned in the makefile, along with the implicit rule that says how to
create it.
Intermediate files are remade using their rules just like all other files. But intermediate files are treated differently in two ways.
The first difference is what happens if the intermediate file does not
exist. If an ordinary file b does not exist, and make
considers a target that depends on b, it invariably creates
b and then updates the target from b. But if b is an
intermediate file, then make
can leave well enough alone. It
won't bother updating b, or the ultimate target, unless some
prerequisite of b is newer than that target or there is some other
reason to update that target.
The second difference is that if make
does create b
in order to update something else, it deletes b later on after it
is no longer needed. Therefore, an intermediate file which did not
exist before make
also does not exist after make
.
make
reports the deletion to you by printing a `rm -f'
command showing which file it is deleting.
Ordinarily, a file cannot be intermediate if it is mentioned in the
makefile as a target or prerequisite. However, you can explicitly mark a
file as intermediate by listing it as a prerequisite of the special target
.INTERMEDIATE
. This takes effect even if the file is mentioned
explicitly in some other way.
You can prevent automatic deletion of an intermediate file by marking it
as a secondary file. To do this, list it as a prerequisite of the
special target .SECONDARY
. When a file is secondary, make
will not create the file merely because it does not already exist, but
make
does not automatically delete the file. Marking a file as
secondary also marks it as intermediate.
You can list the target pattern of an implicit rule (such as `%.o')
as a prerequisite of the special target .PRECIOUS
to preserve
intermediate files made by implicit rules whose target patterns match
that file's name; see section Interrupting or Killing make
.
A chain can involve more than two implicit rules. For example, it is
possible to make a file `foo' from `RCS/foo.y,v' by running RCS,
Yacc and cc
. Then both `foo.y' and `foo.c' are
intermediate files that are deleted at the end.
No single implicit rule can appear more than once in a chain. This means
that make
will not even consider such a ridiculous thing as making
`foo' from `foo.o.o' by running the linker twice. This
constraint has the added benefit of preventing any infinite loop in the
search for an implicit rule chain.
There are some special implicit rules to optimize certain cases that would
otherwise be handled by rule chains. For example, making `foo' from
`foo.c' could be handled by compiling and linking with separate
chained rules, using `foo.o' as an intermediate file. But what
actually happens is that a special rule for this case does the compilation
and linking with a single cc
command. The optimized rule is used in
preference to the step-by-step chain because it comes earlier in the
ordering of rules.
You define an implicit rule by writing a pattern rule. A pattern rule looks like an ordinary rule, except that its target contains the character `%' (exactly one of them). The target is considered a pattern for matching file names; the `%' can match any nonempty substring, while other characters match only themselves. The prerequisites likewise use `%' to show how their names relate to the target name.
Thus, a pattern rule `%.o : %.c' says how to make any file `stem.o' from another file `stem.c'.
Note that expansion using `%' in pattern rules occurs after any variable or function expansions, which take place when the makefile is read. See section How to Use Variables, and section Functions for Transforming Text.
A pattern rule contains the character `%' (exactly one of them) in the target; otherwise, it looks exactly like an ordinary rule. The target is a pattern for matching file names; the `%' matches any nonempty substring, while other characters match only themselves.
For example, `%.c' as a pattern matches any file name that ends in `.c'. `s.%.c' as a pattern matches any file name that starts with `s.', ends in `.c' and is at least five characters long. (There must be at least one character to match the `%'.) The substring that the `%' matches is called the stem.
`%' in a prerequisite of a pattern rule stands for the same stem that was matched by the `%' in the target. In order for the pattern rule to apply, its target pattern must match the file name under consideration, and its prerequisite patterns must name files that exist or can be made. These files become prerequisites of the target.
Thus, a rule of the form
%.o : %.c ; command...
specifies how to make a file `n.o', with another file `n.c' as its prerequisite, provided that `n.c' exists or can be made.
There may also be prerequisites that do not use `%'; such a prerequisite attaches to every file made by this pattern rule. These unvarying prerequisites are useful occasionally.
A pattern rule need not have any prerequisites that contain `%', or in fact any prerequisites at all. Such a rule is effectively a general wildcard. It provides a way to make any file that matches the target pattern. See section Defining Last-Resort Default Rules.
Pattern rules may have more than one target. Unlike normal rules, this
does not act as many different rules with the same prerequisites and
commands. If a pattern rule has multiple targets, make
knows that
the rule's commands are responsible for making all of the targets. The
commands are executed only once to make all the targets. When searching
for a pattern rule to match a target, the target patterns of a rule other
than the one that matches the target in need of a rule are incidental:
make
worries only about giving commands and prerequisites to the file
presently in question. However, when this file's commands are run, the
other targets are marked as having been updated themselves.
The order in which pattern rules appear in the makefile is important since this is the order in which they are considered. Of equally applicable rules, only the first one found is used. The rules you write take precedence over those that are built in. Note however, that a rule whose prerequisites actually exist or are mentioned always takes priority over a rule with prerequisites that must be made by chaining other implicit rules.
Here are some examples of pattern rules actually predefined in
make
. First, the rule that compiles `.c' files into `.o'
files:
%.o : %.c $(CC) -c $(CFLAGS) $(CPPFLAGS) $< -o $@
defines a rule that can make any file `x.o' from `x.c'. The command uses the automatic variables `$@' and `$<' to substitute the names of the target file and the source file in each case where the rule applies (see section Automatic Variables).
Here is a second built-in rule:
% :: RCS/%,v $(CO) $(COFLAGS) $<
defines a rule that can make any file `x' whatsoever from a corresponding file `x,v' in the subdirectory `RCS'. Since the target is `%', this rule will apply to any file whatever, provided the appropriate prerequisite file exists. The double colon makes the rule terminal, which means that its prerequisite may not be an intermediate file (see section Match-Anything Pattern Rules).
This pattern rule has two targets:
%.tab.c %.tab.h: %.y bison -d $<
This tells make
that the command `bison -d x.y' will
make both `x.tab.c' and `x.tab.h'. If the file
`foo' depends on the files `parse.tab.o' and `scan.o'
and the file `scan.o' depends on the file `parse.tab.h',
when `parse.y' is changed, the command `bison -d parse.y'
will be executed only once, and the prerequisites of both
`parse.tab.o' and `scan.o' will be satisfied. (Presumably
the file `parse.tab.o' will be recompiled from `parse.tab.c'
and the file `scan.o' from `scan.c', while `foo' is
linked from `parse.tab.o', `scan.o', and its other
prerequisites, and it will execute happily ever after.)
Suppose you are writing a pattern rule to compile a `.c' file into a `.o' file: how do you write the `cc' command so that it operates on the right source file name? You cannot write the name in the command, because the name is different each time the implicit rule is applied.
What you do is use a special feature of make
, the automatic
variables. These variables have values computed afresh for each rule that
is executed, based on the target and prerequisites of the rule. In this
example, you would use `$@' for the object file name and `$<'
for the source file name.
Here is a table of automatic variables:
$@
$%
make
to Update Archive Files. For example, if the target is `foo.a(bar.o)' then
`$%' is `bar.o' and `$@' is `foo.a'. `$%' is
empty when the target is not an archive member.
$<
$?
make
to Update Archive Files).
$^
make
to Update Archive Files). A target has only one prerequisite on each other file
it depends on, no matter how many times each file is listed as a
prerequisite. So if you list a prerequisite more than once for a target,
the value of $^
contains just one copy of the name.
$+
$*
make
does this bizarre thing only for compatibility
with other implementations of make
. You should generally avoid
using `$*' except in implicit rules or static pattern rules.
If the target name in an explicit rule does not end with a recognized
suffix, `$*' is set to the empty string for that rule.
`$?' is useful even in explicit rules when you wish to operate on only the prerequisites that have changed. For example, suppose that an archive named `lib' is supposed to contain copies of several object files. This rule copies just the changed object files into the archive:
lib: foo.o bar.o lose.o win.o ar r lib $?
Of the variables listed above, four have values that are single file
names, and three have values that are lists of file names. These seven
have variants that get just the file's directory name or just the file
name within the directory. The variant variables' names are formed by
appending `D' or `F', respectively. These variants are
semi-obsolete in GNU make
since the functions dir
and
notdir
can be used to get a similar effect (see section Functions for File Names). Note, however, that the
`F' variants all omit the trailing slash which always appears in
the output of the dir
function. Here is a table of the variants:
Note that we use a special stylistic convention when we talk about these
automatic variables; we write "the value of `$<'", rather than
"the variable <
" as we would write for ordinary variables
such as objects
and CFLAGS
. We think this convention
looks more natural in this special case. Please do not assume it has a
deep significance; `$<' refers to the variable named <
just
as `$(CFLAGS)' refers to the variable named CFLAGS
.
You could just as well use `$(<)' in place of `$<'.
A target pattern is composed of a `%' between a prefix and a suffix, either or both of which may be empty. The pattern matches a file name only if the file name starts with the prefix and ends with the suffix, without overlap. The text between the prefix and the suffix is called the stem. Thus, when the pattern `%.o' matches the file name `test.o', the stem is `test'. The pattern rule prerequisites are turned into actual file names by substituting the stem for the character `%'. Thus, if in the same example one of the prerequisites is written as `%.c', it expands to `test.c'.
When the target pattern does not contain a slash (and it usually does not), directory names in the file names are removed from the file name before it is compared with the target prefix and suffix. After the comparison of the file name to the target pattern, the directory names, along with the slash that ends them, are added on to the prerequisite file names generated from the pattern rule's prerequisite patterns and the file name. The directories are ignored only for the purpose of finding an implicit rule to use, not in the application of that rule. Thus, `e%t' matches the file name `src/eat', with `src/a' as the stem. When prerequisites are turned into file names, the directories from the stem are added at the front, while the rest of the stem is substituted for the `%'. The stem `src/a' with a prerequisite pattern `c%r' gives the file name `src/car'.
When a pattern rule's target is just `%', it matches any file name
whatever. We call these rules match-anything rules. They are very
useful, but it can take a lot of time for make
to think about them,
because it must consider every such rule for each file name listed either
as a target or as a prerequisite.
Suppose the makefile mentions `foo.c'. For this target, make
would have to consider making it by linking an object file `foo.c.o',
or by C compilation-and-linking in one step from `foo.c.c', or by
Pascal compilation-and-linking from `foo.c.p', and many other
possibilities.
We know these possibilities are ridiculous since `foo.c' is a C source
file, not an executable. If make
did consider these possibilities,
it would ultimately reject them, because files such as `foo.c.o' and
`foo.c.p' would not exist. But these possibilities are so
numerous that make
would run very slowly if it had to consider
them.
To gain speed, we have put various constraints on the way make
considers match-anything rules. There are two different constraints that
can be applied, and each time you define a match-anything rule you must
choose one or the other for that rule.
One choice is to mark the match-anything rule as terminal by defining it with a double colon. When a rule is terminal, it does not apply unless its prerequisites actually exist. Prerequisites that could be made with other implicit rules are not good enough. In other words, no further chaining is allowed beyond a terminal rule.
For example, the built-in implicit rules for extracting sources from RCS
and SCCS files are terminal; as a result, if the file `foo.c,v' does
not exist, make
will not even consider trying to make it as an
intermediate file from `foo.c,v.o' or from `RCS/SCCS/s.foo.c,v'.
RCS and SCCS files are generally ultimate source files, which should not be
remade from any other files; therefore, make
can save time by not
looking for ways to remake them.
If you do not mark the match-anything rule as terminal, then it is nonterminal. A nonterminal match-anything rule cannot apply to a file name that indicates a specific type of data. A file name indicates a specific type of data if some non-match-anything implicit rule target matches it.
For example, the file name `foo.c' matches the target for the pattern
rule `%.c : %.y' (the rule to run Yacc). Regardless of whether this
rule is actually applicable (which happens only if there is a file
`foo.y'), the fact that its target matches is enough to prevent
consideration of any nonterminal match-anything rules for the file
`foo.c'. Thus, make
will not even consider trying to make
`foo.c' as an executable file from `foo.c.o', `foo.c.c',
`foo.c.p', etc.
The motivation for this constraint is that nonterminal match-anything rules are used for making files containing specific types of data (such as executable files) and a file name with a recognized suffix indicates some other specific type of data (such as a C source file).
Special built-in dummy pattern rules are provided solely to recognize certain file names so that nonterminal match-anything rules will not be considered. These dummy rules have no prerequisites and no commands, and they are ignored for all other purposes. For example, the built-in implicit rule
%.p :
exists to make sure that Pascal source files such as `foo.p' match a specific target pattern and thereby prevent time from being wasted looking for `foo.p.o' or `foo.p.c'.
Dummy pattern rules such as the one for `%.p' are made for every suffix listed as valid for use in suffix rules (see section Old-Fashioned Suffix Rules).
You can override a built-in implicit rule (or one you have defined yourself) by defining a new pattern rule with the same target and prerequisites, but different commands. When the new rule is defined, the built-in one is replaced. The new rule's position in the sequence of implicit rules is determined by where you write the new rule.
You can cancel a built-in implicit rule by defining a pattern rule with the same target and prerequisites, but no commands. For example, the following would cancel the rule that runs the assembler:
%.o : %.s
You can define a last-resort implicit rule by writing a terminal match-anything pattern rule with no prerequisites (see section Match-Anything Pattern Rules). This is just like any other pattern rule; the only thing special about it is that it will match any target. So such a rule's commands are used for all targets and prerequisites that have no commands of their own and for which no other implicit rule applies.
For example, when testing a makefile, you might not care if the source files contain real data, only that they exist. Then you might do this:
%:: touch $@
to cause all the source files needed (as prerequisites) to be created automatically.
You can instead define commands to be used for targets for which there
are no rules at all, even ones which don't specify commands. You do
this by writing a rule for the target .DEFAULT
. Such a rule's
commands are used for all prerequisites which do not appear as targets in
any explicit rule, and for which no implicit rule applies. Naturally,
there is no .DEFAULT
rule unless you write one.
If you use .DEFAULT
with no commands or prerequisites:
.DEFAULT:
the commands previously stored for .DEFAULT
are cleared.
Then make
acts as if you had never defined .DEFAULT
at all.
If you do not want a target to get the commands from a match-anything
pattern rule or .DEFAULT
, but you also do not want any commands
to be run for the target, you can give it empty commands (see section Using Empty Commands).
You can use a last-resort rule to override part of another makefile. See section Overriding Part of Another Makefile.
Suffix rules are the old-fashioned way of defining implicit rules for
make
. Suffix rules are obsolete because pattern rules are more
general and clearer. They are supported in GNU make
for
compatibility with old makefiles. They come in two kinds:
double-suffix and single-suffix.
A double-suffix rule is defined by a pair of suffixes: the target suffix and the source suffix. It matches any file whose name ends with the target suffix. The corresponding implicit prerequisite is made by replacing the target suffix with the source suffix in the file name. A two-suffix rule whose target and source suffixes are `.o' and `.c' is equivalent to the pattern rule `%.o : %.c'.
A single-suffix rule is defined by a single suffix, which is the source suffix. It matches any file name, and the corresponding implicit prerequisite name is made by appending the source suffix. A single-suffix rule whose source suffix is `.c' is equivalent to the pattern rule `% : %.c'.
Suffix rule definitions are recognized by comparing each rule's target
against a defined list of known suffixes. When make
sees a rule
whose target is a known suffix, this rule is considered a single-suffix
rule. When make
sees a rule whose target is two known suffixes
concatenated, this rule is taken as a double-suffix rule.
For example, `.c' and `.o' are both on the default list of
known suffixes. Therefore, if you define a rule whose target is
`.c.o', make
takes it to be a double-suffix rule with source
suffix `.c' and target suffix `.o'. Here is the old-fashioned
way to define the rule for compiling a C source file:
.c.o: $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
Suffix rules cannot have any prerequisites of their own. If they have any, they are treated as normal files with funny names, not as suffix rules. Thus, the rule:
.c.o: foo.h $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
tells how to make the file `.c.o' from the prerequisite file `foo.h', and is not at all like the pattern rule:
%.o: %.c foo.h $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
which tells how to make `.o' files from `.c' files, and makes all `.o' files using this pattern rule also depend on `foo.h'.
Suffix rules with no commands are also meaningless. They do not remove previous rules as do pattern rules with no commands (see section Canceling Implicit Rules). They simply enter the suffix or pair of suffixes concatenated as a target in the data base.
The known suffixes are simply the names of the prerequisites of the special
target .SUFFIXES
. You can add your own suffixes by writing a rule
for .SUFFIXES
that adds more prerequisites, as in:
.SUFFIXES: .hack .win
which adds `.hack' and `.win' to the end of the list of suffixes.
If you wish to eliminate the default known suffixes instead of just adding
to them, write a rule for .SUFFIXES
with no prerequisites. By
special dispensation, this eliminates all existing prerequisites of
.SUFFIXES
. You can then write another rule to add the suffixes you
want. For example,
.SUFFIXES: # Delete the default suffixes .SUFFIXES: .c .o .h # Define our suffix list
The `-r' or `--no-builtin-rules' flag causes the default list of suffixes to be empty.
The variable SUFFIXES
is defined to the default list of suffixes
before make
reads any makefiles. You can change the list of suffixes
with a rule for the special target .SUFFIXES
, but that does not alter
this variable.
Here is the procedure make
uses for searching for an implicit rule
for a target t. This procedure is followed for each double-colon
rule with no commands, for each target of ordinary rules none of which have
commands, and for each prerequisite that is not the target of any rule. It
is also followed recursively for prerequisites that come from implicit
rules, in the search for a chain of rules.
Suffix rules are not mentioned in this algorithm because suffix rules are converted to equivalent pattern rules once the makefiles have been read in.
For an archive member target of the form `archive(member)', the following algorithm is run twice, first using the entire target name t, and second using `(member)' as the target t if the first run found no rule.
.DEFAULT
, if any,
applies. In that case, give t the same commands that
.DEFAULT
has. Otherwise, there are no commands for t.
Once a rule that applies has been found, for each target pattern of the rule other than the one that matched t or n, the `%' in the pattern is replaced with s and the resultant file name is stored until the commands to remake the target file t are executed. After these commands are executed, each of these stored file names are entered into the data base and marked as having been updated and having the same update status as the file t.
When the commands of a pattern rule are executed for t, the automatic variables are set corresponding to the target and prerequisites. See section Automatic Variables.
make
to Update Archive Files
Archive files are files containing named subfiles called
members; they are maintained with the program ar
and their
main use is as subroutine libraries for linking.
An individual member of an archive file can be used as a target or
prerequisite in make
. You specify the member named member in
archive file archive as follows:
archive(member)
This construct is available only in targets and prerequisites, not in
commands! Most programs that you might use in commands do not support this
syntax and cannot act directly on archive members. Only ar
and
other programs specifically designed to operate on archives can do so.
Therefore, valid commands to update an archive member target probably must
use ar
. For example, this rule says to create a member
`hack.o' in archive `foolib' by copying the file `hack.o':
foolib(hack.o) : hack.o ar cr foolib hack.o
In fact, nearly all archive member targets are updated in just this way
and there is an implicit rule to do it for you. Note: The
`c' flag to ar
is required if the archive file does not
already exist.
To specify several members in the same archive, you can write all the member names together between the parentheses. For example:
foolib(hack.o kludge.o)
is equivalent to:
foolib(hack.o) foolib(kludge.o)
You can also use shell-style wildcards in an archive member reference. See section Using Wildcard Characters in File Names. For example, `foolib(*.o)' expands to all existing members of the `foolib' archive whose names end in `.o'; perhaps `foolib(hack.o) foolib(kludge.o)'.
Recall that a target that looks like `a(m)' stands for the member named m in the archive file a.
When make
looks for an implicit rule for such a target, as a special
feature it considers implicit rules that match `(m)', as well as
those that match the actual target `a(m)'.
This causes one special rule whose target is `(%)' to match. This rule updates the target `a(m)' by copying the file m into the archive. For example, it will update the archive member target `foo.a(bar.o)' by copying the file `bar.o' into the archive `foo.a' as a member named `bar.o'.
When this rule is chained with others, the result is very powerful. Thus, `make "foo.a(bar.o)"' (the quotes are needed to protect the `(' and `)' from being interpreted specially by the shell) in the presence of a file `bar.c' is enough to cause the following commands to be run, even without a makefile:
cc -c bar.c -o bar.o ar r foo.a bar.o rm -f bar.o
Here make
has envisioned the file `bar.o' as an intermediate
file. See section Chains of Implicit Rules.
Implicit rules such as this one are written using the automatic variable `$%'. See section Automatic Variables.
An archive member name in an archive cannot contain a directory name, but
it may be useful in a makefile to pretend that it does. If you write an
archive member target `foo.a(dir/file.o)', make
will perform
automatic updating with this command:
ar r foo.a dir/file.o
which has the effect of copying the file `dir/file.o' into a member
named `file.o'. In connection with such usage, the automatic variables
%D
and %F
may be useful.
An archive file that is used as a library usually contains a special member
named `__.SYMDEF' that contains a directory of the external symbol
names defined by all the other members. After you update any other
members, you need to update `__.SYMDEF' so that it will summarize the
other members properly. This is done by running the ranlib
program:
ranlib archivefile
Normally you would put this command in the rule for the archive file, and make all the members of the archive file prerequisites of that rule. For example,
libfoo.a: libfoo.a(x.o) libfoo.a(y.o) ... ranlib libfoo.a
The effect of this is to update archive members `x.o', `y.o',
etc., and then update the symbol directory member `__.SYMDEF' by
running ranlib
. The rules for updating the members are not shown
here; most likely you can omit them and use the implicit rule which copies
files into the archive, as described in the preceding section.
This is not necessary when using the GNU ar
program, which
updates the `__.SYMDEF' member automatically.
It is important to be careful when using parallel execution (the
-j
switch; see section Parallel Execution) and archives.
If multiple ar
commands run at the same time on the same archive
file, they will not know about each other and can corrupt the file.
Possibly a future version of make
will provide a mechanism to
circumvent this problem by serializing all commands that operate on the
same archive file. But for the time being, you must either write your
makefiles to avoid this problem in some other way, or not use -j
.
You can write a special kind of suffix rule for dealing with archive
files. See section Old-Fashioned Suffix Rules, for a full explanation of suffix rules.
Archive suffix rules are obsolete in GNU make
, because pattern
rules for archives are a more general mechanism (see section Implicit Rule for Archive Member Targets). But they are retained for compatibility with other
make
s.
To write a suffix rule for archives, you simply write a suffix rule using the target suffix `.a' (the usual suffix for archive files). For example, here is the old-fashioned suffix rule to update a library archive from C source files:
.c.a: $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o $(AR) r $@ $*.o $(RM) $*.o
This works just as if you had written the pattern rule:
(%.o): %.c $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o $(AR) r $@ $*.o $(RM) $*.o
In fact, this is just what make
does when it sees a suffix rule
with `.a' as the target suffix. Any double-suffix rule
`.x.a' is converted to a pattern rule with the target
pattern `(%.o)' and a prerequisite pattern of `%.x'.
Since you might want to use `.a' as the suffix for some other kind
of file, make
also converts archive suffix rules to pattern rules
in the normal way (see section Old-Fashioned Suffix Rules). Thus a double-suffix rule
`.x.a' produces two pattern rules: `(%.o):
%.x' and `%.a: %.x'.
make
Here is a summary of the features of GNU make
, for comparison
with and credit to other versions of make
. We consider the
features of make
in 4.2 BSD systems as a baseline. If you are
concerned with writing portable makefiles, you should not use the
features of make
listed here, nor the ones in section Incompatibilities and Missing Features.
Many features come from the version of make
in System V.
VPATH
variable and its special meaning.
See section Searching Directories for Prerequisites.
This feature exists in System V make
, but is undocumented.
It is documented in 4.3 BSD make
(which says it mimics System V's
VPATH
feature).
MAKEFLAGS
to recursive
invocations of make
.
See section Communicating Options to a Sub-make
.
$%
is set to the member name
in an archive reference. See section Automatic Variables.
$@
, $*
, $<
, $%
,
and $?
have corresponding forms like $(@F)
and
$(@D)
. We have generalized this to $^
as an obvious
extension. See section Automatic Variables.
make
, these options actually do something.
make
via the variable
MAKE
even if `-n', `-q' or `-t' is specified.
See section Recursive Use of make
.
make
, because the
general feature of rule chaining (see section Chains of Implicit Rules) allows one pattern rule for installing members in an
archive (see section Implicit Rule for Archive Member Targets) to be sufficient.
The following features were inspired by various other versions of
make
. In some cases it is unclear exactly which versions inspired
which others.
make
.
We're not sure who invented it first, but it's been spread around a bit.
See section Defining and Redefining Pattern Rules.
make
for AT&T Eighth Edition Research Unix, and later by Andrew Hume of
AT&T Bell Labs in his mk
program (where he terms it
"transitive closure"). We do not really know if
we got this from either of them or thought it up ourselves at the
same time. See section Chains of Implicit Rules.
$^
containing a list of all prerequisites
of the current target. We did not invent this, but we have no idea who
did. See section Automatic Variables. The automatic variable
$+
is a simple extension of $^
.
make
) was (as far as we know)
invented by Andrew Hume in mk
.
See section Instead of Executing the Commands.
make
and similar programs, though not in the
System V or BSD implementations. See section Command Execution.
make
by the
patsubst
function before the alternate syntax was implemented
for compatibility with SunOS 4. It is not altogether clear who
inspired whom, since GNU make
had patsubst
before SunOS
4 was released.
make
. See section Appending More Text to Variables.
make
.
See section Archive Members as Targets.
-include
directive to include makefiles with no error for a
nonexistent file comes from SunOS 4 make
. (But note that SunOS 4
make
does not allow multiple makefiles to be specified in one
-include
directive.) The same feature appears with the name
sinclude
in SGI make
and perhaps others.
The remaining features are inventions new in GNU make
:
make
.
MAKE
to recursive make
invocations.
See section Recursive Use of make
.
define
.
See section Defining Variables Verbatim.
.PHONY
.
Andrew Hume of AT&T Bell Labs implemented a similar feature with a
different syntax in his mk
program. This seems to be a case of
parallel discovery. See section Phony Targets.
make
; it seems a natural extension derived from the features
of the C preprocessor and similar macro languages and is not a
revolutionary concept. See section Conditional Parts of Makefiles.
MAKEFILES
.
make
, they must begin with
`.' and not contain any `/' characters.
make
recursion using the
variable MAKELEVEL
. See section Recursive Use of make
.
MAKECMDGOALS
. See section Arguments to Specify the Goals.
vpath
search.
See section Searching Directories for Prerequisites.
make
has a very, very limited form of this
functionality in that it will check out SCCS files for makefiles.
make
.
The make
programs in various other systems support a few features
that are not implemented in GNU make
. The POSIX.2 standard
(IEEE Standard 1003.2-1992) which specifies make
does not
require any of these features.
make
because of the
nonmodularity of putting knowledge into make
of the internal
format of archive file symbol tables.
See section Updating Archive Symbol Directories.
make
;
they refer to the SCCS file that corresponds
to the file one would get without the `~'. For example, the
suffix rule `.c~.o' would make the file `n.o' from
the SCCS file `s.n.c'. For complete coverage, a whole
series of such suffix rules is required.
See section Old-Fashioned Suffix Rules.
In GNU make
, this entire series of cases is handled by two
pattern rules for extraction from SCCS, in combination with the
general feature of rule chaining.
See section Chains of Implicit Rules.
make
, the string `$$@' has the strange meaning
that, in the prerequisites of a rule with multiple targets, it stands
for the particular target that is being processed.
This is not defined in GNU make
because `$$' should always
stand for an ordinary `$'.
It is possible to get portions of this functionality through the use of
static pattern rules (see section Static Pattern Rules).
The System V make
rule:
$(targets<EMAIL_ADDRESS>lib.acan be replaced with the GNU
make
static pattern rule:
$(targets): %: %.o lib.a
make
, files found by VPATH
search
(see section Searching Directories for Prerequisites) have their names changed inside command
strings. We feel it is much cleaner to always use automatic variables
and thus make this feature obsolete.
make
s, the automatic variable $*
appearing in
the prerequisites of a rule has the amazingly strange "feature" of
expanding to the full name of the target of that rule. We cannot
imagine what went on in the minds of Unix make
developers to do
this; it is utterly inconsistent with the normal definition of $*
.
make
s, implicit rule search
(see section Using Implicit Rules) is apparently done for
all targets, not just those without commands. This means you can
do:
foo.o: cc -c foo.cand Unix
make
will intuit that `foo.o' depends on
`foo.c'.
We feel that such usage is broken. The prerequisite properties of
make
are well-defined (for GNU make
, at least),
and doing such a thing simply does not fit the model.
make
does not include any built-in implicit rules for
compiling or preprocessing EFL programs. If we hear of anyone who is
using EFL, we will gladly add them.
make
, a suffix rule can be specified with
no commands, and it is treated as if it had empty commands
(see section Using Empty Commands). For example:
.c.a:will override the built-in `.c.a' suffix rule. We feel that it is cleaner for a rule without commands to always simply add to the prerequisite list for the target. The above example can be easily rewritten to get the desired behavior in GNU
make
:
.c.a: ;
make
invoke the shell with the `-e' flag,
except under `-k' (see section Testing the Compilation of a Program). The `-e' flag tells the shell to exit as soon as any
program it runs returns a nonzero status. We feel it is cleaner to
write each shell command line to stand on its own and not require this
special treatment.
This chapter describes conventions for writing the Makefiles for GNU programs. Using Automake will help you write a Makefile that follows these conventions.
Every Makefile should contain this line:
SHELL = /bin/sh
to avoid trouble on systems where the SHELL
variable might be
inherited from the environment. (This is never a problem with GNU
make
.)
Different make
programs have incompatible suffix lists and
implicit rules, and this sometimes creates confusion or misbehavior. So
it is a good idea to set the suffix list explicitly using only the
suffixes you need in the particular Makefile, like this:
.SUFFIXES: .SUFFIXES: .c .o
The first line clears out the suffix list, the second introduces all suffixes which may be subject to implicit rules in this Makefile.
Don't assume that `.' is in the path for command execution. When you need to run programs that are a part of your package during the make, please make sure that it uses `./' if the program is built as part of the make or `$(srcdir)/' if the file is an unchanging part of the source code. Without one of these prefixes, the current search path is used.
The distinction between `./' (the build directory) and `$(srcdir)/' (the source directory) is important because users can build in a separate directory using the `--srcdir' option to `configure'. A rule of the form:
foo.1 : foo.man sedscript sed -e sedscript foo.man > foo.1
will fail when the build directory is not the source directory, because `foo.man' and `sedscript' are in the the source directory.
When using GNU make
, relying on `VPATH' to find the source
file will work in the case where there is a single dependency file,
since the make
automatic variable `$<' will represent the
source file wherever it is. (Many versions of make
set `$<'
only in implicit rules.) A Makefile target like
foo.o : bar.c $(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
should instead be written as
foo.o : bar.c $(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@
in order to allow `VPATH' to work correctly. When the target has multiple dependencies, using an explicit `$(srcdir)' is the easiest way to make the rule work well. For example, the target above for `foo.1' is best written as:
foo.1 : foo.man sedscript sed -e $(srcdir)/sedscript $(srcdir)/foo.man > $@
GNU distributions usually contain some files which are not source files--for example, Info files, and the output from Autoconf, Automake, Bison or Flex. Since these files normally appear in the source directory, they should always appear in the source directory, not in the build directory. So Makefile rules to update them should put the updated files in the source directory.
However, if a file does not appear in the distribution, then the Makefile should not put it in the source directory, because building a program in ordinary circumstances should not modify the source directory in any way.
Try to make the build and installation targets, at least (and all their
subtargets) work correctly with a parallel make
.
Write the Makefile commands (and any shell scripts, such as
configure
) to run in sh
, not in csh
. Don't use any
special features of ksh
or bash
.
The configure
script and the Makefile rules for building and
installation should not use any utilities directly except these:
cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true
The compression program gzip
can be used in the dist
rule.
Stick to the generally supported options for these programs. For example, don't use `mkdir -p', convenient as it may be, because most systems don't support it.
It is a good idea to avoid creating symbolic links in makefiles, since a few systems don't support them.
The Makefile rules for building and installation can also use compilers
and related programs, but should do so via make
variables so that the
user can substitute alternatives. Here are some of the programs we
mean:
ar bison cc flex install ld ldconfig lex make makeinfo ranlib texi2dvi yacc
Use the following make
variables to run those programs:
$(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX) $(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC)
When you use ranlib
or ldconfig
, you should make sure
nothing bad happens if the system does not have the program in question.
Arrange to ignore an error from that command, and print a message before
the command to tell the user that failure of this command does not mean
a problem. (The Autoconf `AC_PROG_RANLIB' macro can help with
this.)
If you use symbolic links, you should implement a fallback for systems that don't have symbolic links.
Additional utilities that can be used via Make variables are:
chgrp chmod chown mknod
It is ok to use other utilities in Makefile portions (or scripts) intended only for particular systems where you know those utilities exist.
Makefiles should provide variables for overriding certain commands, options, and so on.
In particular, you should run most utility programs via variables.
Thus, if you use Bison, have a variable named BISON
whose default
value is set with `BISON = bison', and refer to it with
$(BISON)
whenever you need to use Bison.
File management utilities such as ln
, rm
, mv
, and
so on, need not be referred to through variables in this way, since users
don't need to replace them with other programs.
Each program-name variable should come with an options variable that is
used to supply options to the program. Append `FLAGS' to the
program-name variable name to get the options variable name--for
example, BISONFLAGS
. (The names CFLAGS
for the C
compiler, YFLAGS
for yacc, and LFLAGS
for lex, are
exceptions to this rule, but we keep them because they are standard.)
Use CPPFLAGS
in any compilation command that runs the
preprocessor, and use LDFLAGS
in any compilation command that
does linking as well as in any direct use of ld
.
If there are C compiler options that must be used for proper
compilation of certain files, do not include them in CFLAGS
.
Users expect to be able to specify CFLAGS
freely themselves.
Instead, arrange to pass the necessary options to the C compiler
independently of CFLAGS
, by writing them explicitly in the
compilation commands or by defining an implicit rule, like this:
CFLAGS = -g ALL_CFLAGS = -I. $(CFLAGS) .c.o: $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
Do include the `-g' option in CFLAGS
, because that is not
required for proper compilation. You can consider it a default
that is only recommended. If the package is set up so that it is
compiled with GCC by default, then you might as well include `-O'
in the default value of CFLAGS
as well.
Put CFLAGS
last in the compilation command, after other variables
containing compiler options, so the user can use CFLAGS
to
override the others.
CFLAGS
should be used in every invocation of the C compiler,
both those which do compilation and those which do linking.
Every Makefile should define the variable INSTALL
, which is the
basic command for installing a file into the system.
Every Makefile should also define the variables INSTALL_PROGRAM
and INSTALL_DATA
. (The default for each of these should be
$(INSTALL)
.) Then it should use those variables as the commands
for actual installation, for executables and nonexecutables
respectively. Use these variables as follows:
$(INSTALL_PROGRAM) foo $(bindir)/foo $(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a
Optionally, you may prepend the value of DESTDIR
to the target
filename. Doing this allows the installer to create a snapshot of the
installation to be copied onto the real target filesystem later. Do not
set the value of DESTDIR
in your Makefile, and do not include it
in any installed files. With support for DESTDIR
, the above
examples become:
$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
Always use a file name, not a directory name, as the second argument of the installation commands. Use a separate command for each file to be installed.
Installation directories should always be named by variables, so it is easy to install in a nonstandard place. The standard names for these variables are described below. They are based on a standard filesystem layout; variants of it are used in SVR4, 4.4BSD, Linux, Ultrix v4, and other modern operating systems.
These two variables set the root for the installation. All the other installation directories should be subdirectories of one of these two, and nothing should be directly installed into these two directories.
prefix
should be `/usr/local'.
When building the complete GNU system, the prefix will be empty and
`/usr' will be a symbolic link to `/'.
(If you are using Autoconf, write it as `<EMAIL_ADDRESS>Running `make install' with a different value of prefix
from the one used to build the program should not recompile
the program.
exec_prefix
should
be $(prefix)
.
(If you are using Autoconf, write it as `<EMAIL_ADDRESS>Generally, $(exec_prefix)
is used for directories that contain
machine-specific files (such as executables and subroutine libraries),
while $(prefix)
is used directly for other directories.
Running `make install' with a different value of exec_prefix
from the one used to build the program should not recompile the
program.
Executable programs are installed in one of the following directories.
Data files used by the program during its execution are divided into categories in two ways.
This makes for six different possibilities. However, we want to discourage the use of architecture-dependent files, aside from object files and libraries. It is much cleaner to make other data files architecture-independent, and it is generally not hard.
Therefore, here are the variables Makefiles should use to specify directories:
libdir
should normally be
`/usr/local/lib', but write it as `$(exec_prefix)/lib'.
(If you are using Autoconf, write it as `<EMAIL_ADDRESS>lispdir='${datadir}/emacs/site-lisp' AC_SUBST(lispdir)
includedir
and one
specified by oldincludedir
.
oldincludedir
is empty. If it is, they should not try to use
it; they should cancel the second installation of the header files.
A package should not replace an existing header in this directory unless
the header came from the same package. Thus, if your Foo package
provides a header file `foo.h', then it should install the header
file in the oldincludedir
directory if either (1) there is no
`foo.h' there or (2) the `foo.h' that exists came from the Foo
package.
To tell whether `foo.h' came from the Foo package, put a magic
string in the file--part of a comment--and grep
for that string.
Unix-style man pages are installed in one of the following:
And finally, you should set the following variable:
configure
shell script.
(If you are using Autconf, use `srcdir =<EMAIL_ADDRESS>For example:
# Common prefix for installation directories. # NOTE: This directory must exist when you start the install. prefix = /usr/local exec_prefix = $(prefix) # Where to put the executable for the command `gcc'. bindir = $(exec_prefix)/bin # Where to put the directories used by the compiler. libexecdir = $(exec_prefix)/libexec # Where to put the Info files. infodir = $(prefix)/info
If your program installs a large number of files into one of the
standard user-specified directories, it might be useful to group them
into a subdirectory particular to that program. If you do this, you
should write the install
rule to create these subdirectories.
Do not expect the user to include the subdirectory name in the value of any of the variables listed above. The idea of having a uniform set of variable names for installation directories is to enable the user to specify the exact same values for several different GNU packages. In order for this to be useful, all the packages must be designed so that they will work sensibly when the user does so.
All GNU programs should have the following targets in their Makefiles:
install-strip
target to do that.
If possible, write the install
target rule so that it does not
modify anything in the directory where the program was built, provided
`make all' has just been done. This is convenient for building the
program under one user name and installing it under another.
The commands should create all the directories in which files are to be
installed, if they don't already exist. This includes the directories
specified as the values of the variables prefix
and
exec_prefix
, as well as all subdirectories that are needed.
One way to do this is by means of an installdirs
target
as described below.
Use `-' before any command for installing a man page, so that
make
will ignore any errors. This is in case there are systems
that don't have the Unix man page documentation system installed.
The way to install Info files is to copy them into `$(infodir)'
with $(INSTALL_DATA)
(see section Variables for Specifying Commands), and then run
the install-info
program if it is present. install-info
is a program that edits the Info `dir' file to add or update the
menu entry for the given Info file; it is part of the Texinfo package.
Here is a sample rule to install an Info file:
$(DESTDIR)$(infodir)/foo.info: foo.info $(POST_INSTALL) # There may be a newer info file in . than in srcdir. -if test -f foo.info; then d=.; \ else d=$(srcdir); fi; \ $(INSTALL_DATA) $$d/foo.info $(DESTDIR)$@; \ # Run install-info only if it exists. # Use `if' instead of just prepending `-' to the # line so we notice real errors from install-info. # We use `$(SHELL) -c' because some shells do not # fail gracefully when there is an unknown command. if $(SHELL) -c 'install-info --version' \ >/dev/null 2>&1; then \ install-info --dir-file=$(DESTDIR)$(infodir)/dir \ $(DESTDIR)$(infodir)/foo.info; \ else true; fiWhen writing the
install
target, you must classify all the
commands into three categories: normal ones, pre-installation
commands and post-installation commands. See section Install Command Categories.
install
, but strip the executable files while installing
them. In many cases, the definition of this target can be very simple:
install-strip: $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \ installNormally we do not recommend stripping an executable unless you are sure the program has no bugs. However, it can be reasonable to install a stripped executable for actual execution while saving the unstripped executable elsewhere in case there is a bug.
distclean
, plus more: C source files produced by
Bison, tags tables, Info files, and so on.
The reason we say "almost everything" is that running the command
`make maintainer-clean' should not delete `configure' even if
`configure' can be remade using a rule in the Makefile. More generally,
`make maintainer-clean' should not delete anything that needs to
exist in order to run `configure' and then begin to build the
program. This is the only exception; maintainer-clean
should
delete everything else that can be rebuilt.
The `maintainer-clean' target is intended to be used by a maintainer of
the package, not by ordinary users. You may need special tools to
reconstruct some of the files that `make maintainer-clean' deletes.
Since these files are normally included in the distribution, we don't
take care to make them easy to reconstruct. If you find you need to
unpack the full distribution again, don't blame us.
To help make users aware of this, the commands for the special
maintainer-clean
target should start with these two:
@echo 'This command is intended for maintainers to use; it' @echo 'deletes files that may need special tools to rebuild.'
info: foo.info foo.info: foo.texi chap1.texi chap2.texi $(MAKEINFO) $(srcdir)/foo.texiYou must define the variable
MAKEINFO
in the Makefile. It should
run the makeinfo
program, which is part of the Texinfo
distribution.
Normally a GNU distribution comes with Info files, and that means the
Info files are present in the source directory. Therefore, the Make
rule for an info file should update it in the source directory. When
users build the package, ordinarily Make will not update the Info files
because they will already be up to date.
dvi: foo.dvi foo.dvi: foo.texi chap1.texi chap2.texi $(TEXI2DVI) $(srcdir)/foo.texiYou must define the variable
TEXI2DVI
in the Makefile. It should
run the program texi2dvi
, which is part of the Texinfo
distribution.(3) Alternatively,
write just the dependencies, and allow GNU make
to provide the command.
ln
or cp
to install the proper files in it, and
then tar
that subdirectory.
Compress the tar file file with gzip
. For example, the actual
distribution file for GCC version 1.40 is called `gcc-1.40.tar.gz'.
The dist
target should explicitly depend on all non-source files
that are in the distribution, to make sure they are up to date in the
distribution.
See section `Making Releases' in GNU Coding Standards.
The following targets are suggested as conventional names, for programs in which they are useful.
installcheck
installdirs
# Make sure all installation directories (e.g. $(bindir)) # actually exist by making them if necessary. installdirs: mkinstalldirs $(srcdir)/mkinstalldirs $(bindir) $(datadir) \ $(libdir) $(infodir) \ $(mandir)This rule should not modify the directories where compilation is done. It should do nothing but create installation directories.
When writing the install
target, you must classify all the
commands into three categories: normal ones, pre-installation
commands and post-installation commands.
Normal commands move files into their proper places, and set their modes. They may not alter any files except the ones that come entirely from the package they belong to.
Pre-installation and post-installation commands may alter other files; in particular, they can edit global configuration files or data bases.
Pre-installation commands are typically executed before the normal commands, and post-installation commands are typically run after the normal commands.
The most common use for a post-installation command is to run
install-info
. This cannot be done with a normal command, since
it alters a file (the Info directory) which does not come entirely and
solely from the package being installed. It is a post-installation
command because it needs to be done after the normal command which
installs the package's Info files.
Most programs don't need any pre-installation commands, but we have the feature just in case it is needed.
To classify the commands in the install
rule into these three
categories, insert category lines among them. A category line
specifies the category for the commands that follow.
A category line consists of a tab and a reference to a special Make variable, plus an optional comment at the end. There are three variables you can use, one for each category; the variable name specifies the category. Category lines are no-ops in ordinary execution because these three Make variables are normally undefined (and you should not define them in the makefile).
Here are the three possible category lines, each with a comment that explains what it means:
$(PRE_INSTALL) # Pre-install commands follow. $(POST_INSTALL) # Post-install commands follow. $(NORMAL_INSTALL) # Normal commands follow.
If you don't use a category line at the beginning of the install
rule, all the commands are classified as normal until the first category
line. If you don't use any category lines, all the commands are
classified as normal.
These are the category lines for uninstall
:
$(PRE_UNINSTALL) # Pre-uninstall commands follow. $(POST_UNINSTALL) # Post-uninstall commands follow. $(NORMAL_UNINSTALL) # Normal commands follow.
Typically, a pre-uninstall command would be used for deleting entries from the Info directory.
If the install
or uninstall
target has any dependencies
which act as subroutines of installation, then you should start
each dependency's commands with a category line, and start the
main target's commands with a category line also. This way, you can
ensure that each command is placed in the right category regardless of
which of the dependencies actually run.
Pre-installation and post-installation commands should not run any programs except for these:
[ basename bash cat chgrp chmod chown cmp cp dd diff echo egrep expand expr false fgrep find getopt grep gunzip gzip hostname install install-info kill ldconfig ln ls md5sum mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee test touch true uname xargs yes
The reason for distinguishing the commands in this way is for the sake of making binary packages. Typically a binary package contains all the executables and other files that need to be installed, and has its own method of installing them--so it does not need to run the normal installation commands. But installing the binary package does need to execute the pre-installation and post-installation commands.
Programs to build binary packages work by extracting the pre-installation and post-installation commands. Here is one way of extracting the pre-installation commands:
make -n install -o all \ PRE_INSTALL=pre-install \ POST_INSTALL=post-install \ NORMAL_INSTALL=normal-install \ | gawk -f pre-install.awk
where the file `pre-install.awk' could contain this:
$0 ~ /^\t[ \t]*(normal_install|post_install)[ \t]*$/ {on = 0} on {print $0} $0 ~ /^\t[ \t]*pre_install[ \t]*$/ {on = 1}
The resulting file of pre-installation commands is executed as a shell script as part of installing the binary package.
This appendix summarizes the directives, text manipulation functions,
and special variables which GNU make
understands.
See section Special Built-in Target Names, section Catalogue of Implicit Rules,
and section Summary of Options,
for other summaries.
Here is a summary of the directives GNU make
recognizes:
define variable
endef
ifdef variable
ifndef variable
ifeq (a,b)
ifeq "a" "b"
ifeq 'a' 'b'
ifneq (a,b)
ifneq "a" "b"
ifneq 'a' 'b'
else
endif
include file
-include file
sinclude file
override variable = value
override variable := value
override variable += value
override variable ?= value
override define variable
endef
override
Directive.
export
make
to export all variables to child processes by default.make
.
export variable
export variable = value
export variable := value
export variable += value
export variable ?= value
unexport variable
make
whether or not to export a particular variable to child
processes.make
.
vpath pattern path
vpath
Directive.
vpath pattern
vpath
vpath
directive.
Here is a summary of the text manipulation functions (see section Functions for Transforming Text):
$(subst from,to,text)
$(patsubst pattern,replacement,text)
$(strip string)
$(findstring find,text)
$(filter pattern...,text)
$(filter-out pattern...,text)
$(sort list)
$(dir names...)
$(notdir names...)
$(suffix names...)
$(basename names...)
$(addsuffix suffix,names...)
$(addprefix prefix,names...)
$(join list1,list2)
$(word n,text)
$(words text)
$(wordlist s,e,text)
$(firstword names...)
$(wildcard pattern...)
wildcard
.
$(error text...)
make
generates a fatal error
with the message text.$(warning text...)
make
generates a warning with
the message text.$(shell command)
shell
Function.
$(origin variable)
make
variable variable was
defined.origin
Function.
$(foreach var,words,text)
foreach
Function.
$(call var,param,...)
$(1)
,
$(2)
with the first, second, etc. param values.call
Function.
Here is a summary of the automatic variables. See section Automatic Variables, for full information.
$@
$%
$<
$?
make
to Update Archive Files).
$^
$+
make
to Update Archive Files). The value of $^
omits duplicate
prerequisites, while $+
retains them and preserves their order.
$*
$(@D)
$(@F)
$@
.
$(*D)
$(*F)
$*
.
$(%D)
$(%F)
$%
.
$(<D)
$(<F)
$<
.
$(^D)
$(^F)
$^
.
$(+D)
$(+F)
$+
.
$(?D)
$(?F)
$?
.
These variables are used specially by GNU make
:
MAKEFILES
make
.MAKEFILES
.
VPATH
VPATH
: Search Path for All Prerequisites.
SHELL
SHELL
in the makefile to change the shell used to run
commands. See section Command Execution.
MAKESHELL
make
. This value takes precedence over the value of
SHELL
. See section Command Execution.
MAKE
make
was invoked.
Using this variable in commands has special meaning.
See section How the MAKE
Variable Works.
MAKELEVEL
make
s).make
.
MAKEFLAGS
make
. You can set this in the environment or
a makefile to set flags.make
.
It is never appropriate to use MAKEFLAGS
directly on a
command line: its contents may not be quoted correctly for use in the
shell. Always allow recursive make
's to obtain these values
through the environment from its parent.
MAKECMDGOALS
make
on the command line. Setting this
variable has no effect on the operation of make
.CURDIR
-C
options are processed, if any). Setting this variable has no
effect on the operation of make
.make
.
SUFFIXES
make
reads any makefiles.
.LIBPATTERNS
make
searches for, and their
order.
Here is a list of the more common errors you might see generated by
make
, and some information about what they mean and how to fix
them.
Sometimes make
errors are not fatal, especially in the presence
of a -
prefix on a command script line, or the -k
command
line option. Errors that are fatal are prefixed with the string
***
.
Error messages are all either prefixed with the name of the program (usually `make'), or, if the error is found in a makefile, the name of the file and linenumber containing the problem.
In the table below, these common prefixes are left off.
make
errors at all. They mean that a
program that make
invoked as part of a command script returned a
non-0 error code (`Error NN'), which make
interprets
as failure, or it exited in some other abnormal fashion (with a
signal of some type). See section Errors in Commands.
If no ***
is attached to the message, then the subprocess failed
but the rule in the makefile was prefixed with the -
special
character, so make
ignored the error.
make
could not understand much of anything about
the command line it just read. GNU make
looks for various kinds
of separators (:
, =
, TAB characters, etc.) to help it
decide what kind of commandline it's seeing. This means it couldn't
find a valid one.
One of the most common reasons for this message is that you (or perhaps
your oh-so-helpful editor, as is the case with many MS-Windows editors)
have attempted to indent your command scripts with spaces instead of a
TAB character. In this case, make
will use the second form of
the error above. Remember that every line in the command script must
begin with a TAB character. Eight spaces do not count. See section Rule Syntax.
make
command (such as a variable assignment). Command scripts
must always be associated with a target.
The second form is generated if the line has a semicolon as the first
non-whitespace character; make
interprets this to mean you left
out the "target: prerequisite" section of a rule. See section Rule Syntax.
make
decided it needed to build a target, but
then couldn't find any instructions in the makefile on how to do that,
either explicit or implicit (including in the default rules database).
If you want that file to be built, you will need to add a rule to your
makefile describing how that target can be built. Other possible
sources of this problem are typos in the makefile (if that filename is
wrong) or a corrupted source tree (if that file is not supposed to be
built, but rather only a prerequisite).
make
couldn't find any makefiles to read in.
The latter means that some makefile was found, but it didn't contain any
default target and none was given on the command line. GNU make
has nothing to do in these situations.
See section Arguments to Specify the Makefile.
make
allows commands to be specified only once per target
(except for double-colon rules). If you give commands for a target
which already has been defined to have commands, this warning is issued
and the second set of commands will overwrite the first set.
See section Multiple Rules for One Target.
make
detected a loop in the dependency graph:
after tracing the prerequisite yyy of target xxx, and its
prerequisites, etc., one of them depended on xxx again.
make
variable
xxx that, when it's expanded, will refer to itself (xxx).
This is not allowed; either use simply-expanded variables (:=
) or
use the append operator (+=
). See section How to Use Variables.
%
). See section Syntax of Static Pattern Rules.
make
detects error
conditions related to parallel processing on systems where
sub-make
s can communicate (see section Communicating Options to a Sub-make
). This warning is
generated if a recursive invocation of a make
process is forced
to have `-jN' in its argument list (where N is greater
than one). This could happen, for example, if you set the MAKE
environment variable to `make -j2'. In this case, the
sub-make
doesn't communicate with other make
processes and
will simply pretend it has two jobs of its own.
make
processes to communicate, the parent will pass
information to the child. Since this could result in problems if the
child process isn't actually a make
, the parent will only do this
if it thinks the child is a make
. The parent uses the normal
algorithms to determine this (see section How the MAKE
Variable Works). If the makefile is constructed such that the parent
doesn't know the child is a make
process, then the child will
receive only part of the information necessary. In this case, the child
will generate this warning message and proceed with its build in a
sequential manner.
Here is the makefile for the GNU tar
program. This is a
moderately complex makefile.
Because it is the first target, the default goal is `all'. An
interesting feature of this makefile is that `testpad.h' is a
source file automatically created by the testpad
program,
itself compiled from `testpad.c'.
If you type `make' or `make all', then make
creates
the `tar' executable, the `rmt' daemon that provides
remote tape access, and the `tar.info' Info file.
If you type `make install', then make
not only creates
`tar', `rmt', and `tar.info', but also installs
them.
If you type `make clean', then make
removes the `.o'
files, and the `tar', `rmt', `testpad',
`testpad.h', and `core' files.
If you type `make distclean', then make
not only removes
the same files as does `make clean' but also the
`TAGS', `Makefile', and `config.status' files.
(Although it is not evident, this makefile (and
`config.status') is generated by the user with the
configure
program, which is provided in the tar
distribution, but is not shown here.)
If you type `make realclean', then make
removes the same
files as does `make distclean' and also removes the Info files
generated from `tar.texinfo'.
In addition, there are targets shar
and dist
that create
distribution kits.
# Generated automatically from Makefile.in by configure. # Un*x Makefile for GNU tar program. # Copyright (C) 1991 Free Software Foundation, Inc. # This program is free software; you can redistribute # it and/or modify it under the terms of the GNU # General Public License ... ... ... SHELL = /bin/sh #### Start of system configuration section. #### srcdir = . # If you use gcc, you should either run the # fixincludes script that comes with it or else use # gcc with the -traditional option. Otherwise ioctl # calls will be compiled incorrectly on some systems. CC = gcc -O YACC = bison -y INSTALL = /usr/local/bin/install -c INSTALLDATA = /usr/local/bin/install -c -m 644 # Things you might add to DEFS: # -DSTDC_HEADERS If you have ANSI C headers and # libraries. # -DPOSIX If you have POSIX.1 headers and # libraries. # -DBSD42 If you have sys/dir.h (unless # you use -DPOSIX), sys/file.h, # and st_blocks in `struct stat'. # -DUSG If you have System V/ANSI C # string and memory functions # and headers, sys/sysmacros.h, # fcntl.h, getcwd, no valloc, # and ndir.h (unless # you use -DDIRENT). # -DNO_MEMORY_H If USG or STDC_HEADERS but do not # include memory.h. # -DDIRENT If USG and you have dirent.h # instead of ndir.h. # -DSIGTYPE=int If your signal handlers # return int, not void. # -DNO_MTIO If you lack sys/mtio.h # (magtape ioctls). # -DNO_REMOTE If you do not have a remote shell # or rexec. # -DUSE_REXEC To use rexec for remote tape # operations instead of # forking rsh or remsh. # -DVPRINTF_MISSING If you lack vprintf function # (but have _doprnt). # -DDOPRNT_MISSING If you lack _doprnt function. # Also need to define # -DVPRINTF_MISSING. # -DFTIME_MISSING If you lack ftime system call. # -DSTRSTR_MISSING If you lack strstr function. # -DVALLOC_MISSING If you lack valloc function. # -DMKDIR_MISSING If you lack mkdir and # rmdir system calls. # -DRENAME_MISSING If you lack rename system call. # -DFTRUNCATE_MISSING If you lack ftruncate # system call. # -DV7 On Version 7 Unix (not # tested in a long time). # -DEMUL_OPEN3 If you lack a 3-argument version # of open, and want to emulate it # with system calls you do have. # -DNO_OPEN3 If you lack the 3-argument open # and want to disable the tar -k # option instead of emulating open. # -DXENIX If you have sys/inode.h # and need it 94 to be included. DEFS = -DSIGTYPE=int -DDIRENT -DSTRSTR_MISSING \ -DVPRINTF_MISSING -DBSD42 # Set this to rtapelib.o unless you defined NO_REMOTE, # in which case make it empty. RTAPELIB = rtapelib.o LIBS = DEF_AR_FILE = /dev/rmt8 DEFBLOCKING = 20 CDEBUG = -g CFLAGS = $(CDEBUG) -I. -I$(srcdir) $(DEFS) \ -DDEF_AR_FILE=\"$(DEF_AR_FILE)\" \ -DDEFBLOCKING=$(DEFBLOCKING) LDFLAGS = -g prefix = /usr/local # Prefix for each installed program, # normally empty or `g'. binprefix = # The directory to install tar in. bindir = $(prefix)/bin # The directory to install the info files in. infodir = $(prefix)/info #### End of system configuration section. #### SRC1 = tar.c create.c extract.c buffer.c \ getoldopt.c update.c gnu.c mangle.c SRC2 = version.c list.c names.c diffarch.c \ port.c wildmat.c getopt.c SRC3 = getopt1.c regex.c getdate.y SRCS = $(SRC1) $(SRC2) $(SRC3) OBJ1 = tar.o create.o extract.o buffer.o \ getoldopt.o update.o gnu.o mangle.o OBJ2 = version.o list.o names.o diffarch.o \ port.o wildmat.o getopt.o OBJ3 = getopt1.o regex.o getdate.o $(RTAPELIB) OBJS = $(OBJ1) $(OBJ2) $(OBJ3) AUX = README COPYING ChangeLog Makefile.in \ makefile.pc configure configure.in \ tar.texinfo tar.info* texinfo.tex \ tar.h port.h open3.h getopt.h regex.h \ rmt.h rmt.c rtapelib.c alloca.c \ msd_dir.h msd_dir.c tcexparg.c \ level-0 level-1 backup-specs testpad.c all: tar rmt tar.info tar: $(OBJS) $(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS) rmt: rmt.c $(CC) $(CFLAGS) $(LDFLAGS) -o $@ rmt.c tar.info: tar.texinfo makeinfo tar.texinfo install: all $(INSTALL) tar $(bindir)/$(binprefix)tar -test ! -f rmt || $(INSTALL) rmt /etc/rmt $(INSTALLDATA) $(srcdir)/tar.info* $(infodir) $(OBJS): tar.h port.h testpad.h regex.o buffer.o tar.o: regex.h # getdate.y has 8 shift/reduce conflicts. testpad.h: testpad ./testpad testpad: testpad.o $(CC) -o $@ testpad.o TAGS: $(SRCS) etags $(SRCS) clean: rm -f *.o tar rmt testpad testpad.h core distclean: clean rm -f TAGS Makefile config.status realclean: distclean rm -f tar.info* shar: $(SRCS) $(AUX) shar $(SRCS) $(AUX) | compress \ > tar-`sed -e '/version_string/!d' \ -e 's/[^0-9.]*\([0-9.]*\).*/\1/' \ -e q version.c`.shar.Z dist: $(SRCS) $(AUX) echo tar-`sed \ -e '/version_string/!d' \ -e 's/[^0-9.]*\([0-9.]*\).*/\1/' \ -e q version.c` > .fname -rm -rf `cat .fname` mkdir `cat .fname` ln $(SRCS) $(AUX) `cat .fname` tar chZf `cat .fname`.tar.Z `cat .fname` -rm -rf `cat .fname` .fname tar.zoo: $(SRCS) $(AUX) -rm -rf tmp.dir -mkdir tmp.dir -rm tar.zoo for X in $(SRCS) $(AUX) ; do \ echo $$X ; \ sed 's/$$/^M/' $$X \ > tmp.dir/$$X ; done cd tmp.dir ; zoo aM ../tar.zoo * -rm -rf tmp.dir
#
(comments), in commands
#
(comments), in makefile
#include
$
, in function call
$
, in rules
$
, in variable name
$
, in variable reference
%
, in pattern rules
%
, quoting in static pattern
%
, quoting in patsubst
%
, quoting in vpath
%
, quoting with \
(backslash), %
, quoting with \
(backslash), %
, quoting with \
(backslash)
*
(wildcard character)
define
-
(in commands)
define
--assume-new
, --assume-new
--assume-new
, and recursion
--assume-old
, --assume-old
--assume-old
, and recursion
--debug
--directory
, --directory
--directory
, and recursion
--directory
, and --print-directory
--dry-run
, --dry-run
, --dry-run
--environment-overrides
--file
, --file
, --file
--file
, and recursion
--help
--ignore-errors
, --ignore-errors
--include-dir
, --include-dir
--jobs
, --jobs
--jobs
, and recursion
--just-print
, --just-print
, --just-print
--keep-going
, --keep-going
, --keep-going
--load-average
, --load-average
--makefile
, --makefile
, --makefile
--max-load
, --max-load
--new-file
, --new-file
--new-file
, and recursion
--no-builtin-rules
--no-builtin-variables
--no-keep-going
--no-print-directory
, --no-print-directory
--old-file
, --old-file
--old-file
, and recursion
--print-data-base
--print-directory
--print-directory
, and recursion
--print-directory
, disabling
--print-directory
, and --directory
--question
, --question
--quiet
, --quiet
--recon
, --recon
, --recon
--silent
, --silent
--stop
--touch
, --touch
--touch
, and recursion
--version
--warn-undefined-variables
--what-if
, --what-if
-b
-C
, -C
-C
, and recursion
-C
, and -w
-d
-e
-e
(shell flag)
-f
, -f
, -f
-f
, and recursion
-h
-I
, -I
-i
, -i
-j
, -j
-j
, and archive update
-j
, and recursion
-k
, -k
, -k
-l
-l
(library search)
-l
(load average)
-m
-M
(to compiler)
-MM
(to GNU compiler)
-n
, -n
, -n
-o
, -o
-o
, and recursion
-p
-q
, -q
-R
-r
-S
-s
, -s
-t
, -t
-t
, and recursion
-v
-W
, -W
-w
-W
, and recursion
-w
, and recursion
-w
, disabling
-w
, and -C
.a
(archives)
.d
.LIBPATTERNS
, and link libraries
.PRECIOUS
intermediate files
::
rules (double-colon)
?
(wildcard character)
@
(in commands)
define
[...]
(wildcard characters)
\
(backslash), for continuation lines
\
(backslash), in commands
\
(backslash), to quote %
, \
(backslash), to quote %
, \
(backslash), to quote %
__.SYMDEF
all
(standard target)
-j
\
), for continuation lines
\
), in commands
\
), to quote %
, backslash (\
), to quote %
, backslash (\
), to quote %
cd
(shell command), cd
(shell command)
check
(standard target)
clean
(standard target)
clean
target, clean
target
clobber
(standard target)
\
) in
make
rules
VPATH
)
VPATH
), and implicit rules
VPATH
), and link libraries
VPATH
), and shell commands
dist
(standard target)
distclean
(standard target)
$
), in function call
$
), in rules
$
), in variable name
$
), in variable reference
M-x compile
)
SHELL
in
make
FORCE
VPATH
MAKEFILES
variable)
install
(standard target)
lint
, rule to run
lpr
(shell command), lpr
(shell command)
make depend
MAKECMDGOALS
MAKEFILES
variable
make
processes
mostlyclean
(standard target)
::
)
OBJ
obj
OBJECTS
objects
OBJS
objs
override
.PRECIOUS
, preserving with .PRECIOUS
.SECONDARY
print
(standard target)
print
target, print
target
%
, in static pattern
%
, in patsubst
%
, in vpath
README
realclean
(standard target)
-C
-f
-j
-o
-t
-W
-w
MAKE
variable
MAKEFILES
variable
rm
(shell command), rm
(shell command), rm
(shell command), rm
(shell command)
$
::
)
VPATH
VPATH
)
VPATH
), and implicit rules
VPATH
), and link libraries
sed
(shell command)
shar
(standard target)
include
)
include
)
SHELL
, MS-DOS specifics
make
TAGS
(standard target)
tar
(standard target)
test
(standard target)
~
)
touch
(shell command), touch
(shell command)
VPATH
, and implicit rules
VPATH
, and link libraries
include
yacc
~
(tilde)
GNU Make compiled for MS-DOS and MS-Windows behaves as if prefix has been defined to be the root of the DJGPP tree hierarchy.