version, based off of 3.74, seems to have problems with NSPR autoconf. r=cls. git-svn-id: svn://10.0.0.236/trunk@85225 18797224-902f-48f8-a5cc-f745e15eee43
1202 lines
47 KiB
Plaintext
1202 lines
47 KiB
Plaintext
This is make.info, produced by makeinfo version 4.0 from make.texinfo.
|
||
|
||
INFO-DIR-SECTION GNU Packages
|
||
START-INFO-DIR-ENTRY
|
||
* Make: (make). Remake files automatically.
|
||
END-INFO-DIR-ENTRY
|
||
|
||
This file documents the GNU Make utility, which determines
|
||
automatically which pieces of a large program need to be recompiled,
|
||
and issues the commands to recompile them.
|
||
|
||
This is Edition 0.55, last updated 04 April 2000, of `The GNU Make
|
||
Manual', for `make', Version 3.79.
|
||
|
||
Copyright (C) 1988, '89, '90, '91, '92, '93, '94, '95, '96, '97,
|
||
'98, '99, 2000 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided that
|
||
the entire resulting derived work is distributed under the terms of a
|
||
permission notice identical to this one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions, except that this permission notice may be stated in a
|
||
translation approved by the Free Software Foundation.
|
||
|
||
|
||
File: make.info, Node: File Name Functions, Next: Foreach Function, Prev: Text Functions, Up: Functions
|
||
|
||
Functions for File Names
|
||
========================
|
||
|
||
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...)'
|
||
Extracts the directory-part of each file name in NAMES. The
|
||
directory-part of the file name is everything up through (and
|
||
including) the last slash in it. If the file name contains no
|
||
slash, the directory part is the string `./'. For example,
|
||
|
||
$(dir src/foo.c hacks)
|
||
|
||
produces the result `src/ ./'.
|
||
|
||
`$(notdir NAMES...)'
|
||
Extracts all but the directory-part of each file name in NAMES.
|
||
If the file name contains no slash, it is left unchanged.
|
||
Otherwise, everything through the last slash is removed from it.
|
||
|
||
A file name that ends with a slash becomes an empty string. This
|
||
is unfortunate, because it means that the result does not always
|
||
have the same number of whitespace-separated file names as the
|
||
argument had; but we do not see any other valid alternative.
|
||
|
||
For example,
|
||
|
||
$(notdir src/foo.c hacks)
|
||
|
||
produces the result `foo.c hacks'.
|
||
|
||
`$(suffix NAMES...)'
|
||
Extracts the suffix of each file name in NAMES. If the file name
|
||
contains a period, the suffix is everything starting with the last
|
||
period. Otherwise, the suffix is the empty string. This
|
||
frequently means that the result will be empty when NAMES is not,
|
||
and if NAMES contains multiple file names, the result may contain
|
||
fewer file names.
|
||
|
||
For example,
|
||
|
||
$(suffix src/foo.c src-1.0/bar.c hacks)
|
||
|
||
produces the result `.c .c'.
|
||
|
||
`$(basename NAMES...)'
|
||
Extracts all but the suffix of each file name in NAMES. If the
|
||
file name contains a period, the basename is everything starting
|
||
up to (and not including) the last period. Periods in the
|
||
directory part are ignored. If there is no period, the basename
|
||
is the entire file name. For example,
|
||
|
||
$(basename src/foo.c src-1.0/bar hacks)
|
||
|
||
produces the result `src/foo src-1.0/bar hacks'.
|
||
|
||
`$(addsuffix SUFFIX,NAMES...)'
|
||
The argument NAMES is regarded as a series of names, separated by
|
||
whitespace; SUFFIX is used as a unit. The value of SUFFIX is
|
||
appended to the end of each individual name and the resulting
|
||
larger names are concatenated with single spaces between them.
|
||
For example,
|
||
|
||
$(addsuffix .c,foo bar)
|
||
|
||
produces the result `foo.c bar.c'.
|
||
|
||
`$(addprefix PREFIX,NAMES...)'
|
||
The argument NAMES is regarded as a series of names, separated by
|
||
whitespace; PREFIX is used as a unit. The value of PREFIX is
|
||
prepended to the front of each individual name and the resulting
|
||
larger names are concatenated with single spaces between them.
|
||
For example,
|
||
|
||
$(addprefix src/,foo bar)
|
||
|
||
produces the result `src/foo src/bar'.
|
||
|
||
`$(join LIST1,LIST2)'
|
||
Concatenates the two arguments word by word: the two first words
|
||
(one from each argument) concatenated form the first word of the
|
||
result, the two second words form the second word of the result,
|
||
and so on. So the Nth word of the result comes from the Nth word
|
||
of each argument. If one argument has more words that the other,
|
||
the extra words are copied unchanged into the result.
|
||
|
||
For example, `$(join a b,.c .o)' produces `a.c b.o'.
|
||
|
||
Whitespace between the words in the lists is not preserved; it is
|
||
replaced with a single space.
|
||
|
||
This function can merge the results of the `dir' and `notdir'
|
||
functions, to produce the original list of files which was given
|
||
to those two functions.
|
||
|
||
`$(word N,TEXT)'
|
||
Returns the Nth word of TEXT. The legitimate values of N start
|
||
from 1. If N is bigger than the number of words in TEXT, the
|
||
value is empty. For example,
|
||
|
||
$(word 2, foo bar baz)
|
||
|
||
returns `bar'.
|
||
|
||
`$(wordlist S,E,TEXT)'
|
||
Returns the list of words in TEXT starting with word S and ending
|
||
with word E (inclusive). The legitimate values of S and E start
|
||
from 1. If S is bigger than the number of words in TEXT, the
|
||
value is empty. If E is bigger than the number of words in TEXT,
|
||
words up to the end of TEXT are returned. If S is greater than E,
|
||
nothing is returned. For example,
|
||
|
||
$(wordlist 2, 3, foo bar baz)
|
||
|
||
returns `bar baz'.
|
||
|
||
`$(words TEXT)'
|
||
Returns the number of words in TEXT. Thus, the last word of TEXT
|
||
is `$(word $(words TEXT),TEXT)'.
|
||
|
||
`$(firstword NAMES...)'
|
||
The argument NAMES is regarded as a series of names, separated by
|
||
whitespace. The value is the first name in the series. The rest
|
||
of the names are ignored.
|
||
|
||
For example,
|
||
|
||
$(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)'
|
||
The argument PATTERN is a file name pattern, typically containing
|
||
wildcard characters (as in shell file name patterns). The result
|
||
of `wildcard' is a space-separated list of the names of existing
|
||
files that match the pattern. *Note Using Wildcard Characters in
|
||
File Names: Wildcards.
|
||
|
||
|
||
File: make.info, Node: Foreach Function, Next: If Function, Prev: File Name Functions, Up: Functions
|
||
|
||
The `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. *Note The Two Flavors of Variables:
|
||
Flavors.
|
||
|
||
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.
|
||
|
||
|
||
File: make.info, Node: If Function, Next: Call Function, Prev: Foreach Function, Up: Functions
|
||
|
||
The `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' (*note Syntax of Conditionals: Conditional Syntax.).
|
||
|
||
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.)
|
||
|
||
|
||
File: make.info, Node: Call Function, Next: Origin Function, Prev: If Function, Up: Functions
|
||
|
||
The `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'.
|
||
|
||
|
||
File: make.info, Node: Origin Function, Next: Shell Function, Prev: Call Function, Up: Functions
|
||
|
||
The `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:
|
||
|
||
`undefined'
|
||
if VARIABLE was never defined.
|
||
|
||
`default'
|
||
if VARIABLE has a default definition, as is usual with `CC' and so
|
||
on. *Note Variables Used by Implicit Rules: Implicit Variables.
|
||
Note that if you have redefined a default variable, the `origin'
|
||
function will return the origin of the later definition.
|
||
|
||
`environment'
|
||
if VARIABLE was defined as an environment variable and the `-e'
|
||
option is _not_ turned on (*note Summary of Options: Options
|
||
Summary.).
|
||
|
||
`environment override'
|
||
if VARIABLE was defined as an environment variable and the `-e'
|
||
option _is_ turned on (*note Summary of Options: Options Summary.).
|
||
|
||
`file'
|
||
if VARIABLE was defined in a makefile.
|
||
|
||
`command line'
|
||
if VARIABLE was defined on the command line.
|
||
|
||
`override'
|
||
if VARIABLE was defined with an `override' directive in a makefile
|
||
(*note The `override' Directive: Override Directive.).
|
||
|
||
`automatic'
|
||
if VARIABLE is an automatic variable defined for the execution of
|
||
the commands for each rule (*note Automatic Variables: Automatic.).
|
||
|
||
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'. *Note Functions for
|
||
String Substitution and Analysis: Text Functions.
|
||
|
||
|
||
File: make.info, Node: Shell Function, Next: Make Control Functions, Prev: Origin Function, Up: Functions
|
||
|
||
The `shell' Function
|
||
====================
|
||
|
||
The `shell' function is unlike any other function except the
|
||
`wildcard' function (*note The Function `wildcard': Wildcard Function.)
|
||
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)'.
|
||
|
||
|
||
File: make.info, Node: Make Control Functions, Prev: Shell Function, Up: Functions
|
||
|
||
Functions That Control Make
|
||
===========================
|
||
|
||
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...)'
|
||
Generates a fatal error where the message is TEXT. Note that the
|
||
error is generated whenever this function is evaluated. So, if
|
||
you put it inside a command script or on the right side of a
|
||
recursive variable assignment, it won't be evaluated until later.
|
||
The TEXT will be expanded before the error is generated.
|
||
|
||
For example,
|
||
|
||
ifdef ERROR1
|
||
$(error error is $(ERROR1))
|
||
endif
|
||
|
||
will 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...)'
|
||
This function works similarly to the `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.
|
||
|
||
|
||
File: make.info, Node: Running, Next: Implicit Rules, Prev: Functions, Up: Top
|
||
|
||
How to Run `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'
|
||
The exit status is zero if `make' is successful.
|
||
|
||
`2'
|
||
The exit status is two if `make' encounters any errors. It will
|
||
print messages describing the particular errors.
|
||
|
||
`1'
|
||
The exit status is one if you use the `-q' flag and `make'
|
||
determines that some target is not already up to date. *Note
|
||
Instead of Executing the Commands: Instead of Execution.
|
||
|
||
* Menu:
|
||
|
||
* Makefile Arguments:: How to specify which makefile to use.
|
||
* Goals:: How to use goal arguments to specify which
|
||
parts of the makefile to use.
|
||
* Instead of Execution:: How to use mode flags to specify what
|
||
kind of thing to do with the commands
|
||
in the makefile other than simply
|
||
execute them.
|
||
* Avoiding Compilation:: How to avoid recompiling certain files.
|
||
* Overriding:: How to override a variable to specify
|
||
an alternate compiler and other things.
|
||
* Testing:: How to proceed past some errors, to
|
||
test compilation.
|
||
* Options Summary:: Summary of Options
|
||
|
||
|
||
File: make.info, Node: Makefile Arguments, Next: Goals, Up: Running
|
||
|
||
Arguments to Specify the Makefile
|
||
=================================
|
||
|
||
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 (*note Writing
|
||
Makefiles: Makefiles.).
|
||
|
||
|
||
File: make.info, Node: Goals, Next: Instead of Execution, Prev: Makefile Arguments, Up: Running
|
||
|
||
Arguments to Specify the Goals
|
||
==============================
|
||
|
||
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 (*note Automatic Prerequisites::), 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 (*note Phony Targets::) or empty target (*note
|
||
Empty Target Files to Record Events: Empty Targets.). 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. *Note Standard Targets::, for a detailed list of
|
||
all the standard target names which GNU software packages use.
|
||
|
||
`all'
|
||
Make all the top-level targets the makefile knows about.
|
||
|
||
`clean'
|
||
Delete all files that are normally created by running `make'.
|
||
|
||
`mostlyclean'
|
||
Like `clean', but may refrain from deleting a few files that people
|
||
normally don't want to recompile. For example, the `mostlyclean'
|
||
target for GCC does not delete `libgcc.a', because recompiling it
|
||
is rarely necessary and takes a lot of time.
|
||
|
||
`distclean'
|
||
`realclean'
|
||
`clobber'
|
||
Any of these targets might be defined to delete _more_ files than
|
||
`clean' does. For example, this would delete configuration files
|
||
or links that you would normally create as preparation for
|
||
compilation, even if the makefile itself cannot create these files.
|
||
|
||
`install'
|
||
Copy the executable file into a directory that users typically
|
||
search for commands; copy any auxiliary files that the executable
|
||
uses into the directories where it will look for them.
|
||
|
||
`print'
|
||
Print listings of the source files that have changed.
|
||
|
||
`tar'
|
||
Create a tar file of the source files.
|
||
|
||
`shar'
|
||
Create a shell archive (shar file) of the source files.
|
||
|
||
`dist'
|
||
Create a distribution file of the source files. This might be a
|
||
tar file, or a shar file, or a compressed version of one of the
|
||
above, or even more than one of the above.
|
||
|
||
`TAGS'
|
||
Update a tags table for this program.
|
||
|
||
`check'
|
||
`test'
|
||
Perform self tests on the program this makefile builds.
|
||
|
||
|
||
File: make.info, Node: Instead of Execution, Next: Avoiding Compilation, Prev: Goals, Up: Running
|
||
|
||
Instead of Executing the Commands
|
||
=================================
|
||
|
||
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'.
|
||
|
||
`-n'
|
||
`--just-print'
|
||
`--dry-run'
|
||
`--recon'
|
||
"No-op". The activity is to print what commands would be used to
|
||
make the targets up to date, but not actually execute them.
|
||
|
||
`-t'
|
||
`--touch'
|
||
"Touch". The activity is to mark the targets as up to date without
|
||
actually changing them. In other words, `make' pretends to compile
|
||
the targets but does not really change their contents.
|
||
|
||
`-q'
|
||
`--question'
|
||
"Question". The activity is to find out silently whether the
|
||
targets are up to date already; but execute no commands in either
|
||
case. In other words, neither compilation nor output will occur.
|
||
|
||
`-W FILE'
|
||
`--what-if=FILE'
|
||
`--assume-new=FILE'
|
||
`--new-file=FILE'
|
||
"What if". Each `-W' flag is followed by a file name. The given
|
||
files' modification times are recorded by `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}' (*Note How the `MAKE' Variable Works:
|
||
MAKE Variable.)
|
||
|
||
The `-W' flag provides two features:
|
||
|
||
* If you also use the `-n' or `-q' flag, you can see what `make'
|
||
would do if you were to modify some files.
|
||
|
||
* Without the `-n' or `-q' flag, when `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 (*note Summary
|
||
of Options: Options Summary.).
|
||
|
||
|
||
File: make.info, Node: Avoiding Compilation, Next: Overriding, Prev: Instead of Execution, Up: Running
|
||
|
||
Avoiding Recompilation of Some Files
|
||
====================================
|
||
|
||
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:
|
||
|
||
1. Use the command `make' to recompile the source files that really
|
||
need recompilation.
|
||
|
||
2. Make the changes in the header files.
|
||
|
||
3. Use the command `make -t' to mark all the object files as up to
|
||
date. The next time you run `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" (*note
|
||
Summary of Options: Options Summary.). This means that the file itself
|
||
will not be remade, and nothing else will be remade on its account.
|
||
Follow this procedure:
|
||
|
||
1. Recompile the source files that need compilation for reasons
|
||
independent of the particular header file, with `make -o
|
||
HEADERFILE'. If several header files are involved, use a separate
|
||
`-o' option for each header file.
|
||
|
||
2. Touch all the object files with `make -t'.
|
||
|
||
|
||
File: make.info, Node: Overriding, Next: Testing, Prev: Avoiding Compilation, Up: Running
|
||
|
||
Overriding Variables
|
||
====================
|
||
|
||
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. *Note Variables Used
|
||
by Implicit Rules: Implicit Variables, 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' (*note The
|
||
`override' Directive: Override Directive.).
|
||
|
||
|
||
File: make.info, Node: Testing, Next: Options Summary, Prev: Overriding, Up: Running
|
||
|
||
Testing the Compilation of a Program
|
||
====================================
|
||
|
||
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 (*note Summary of
|
||
Options: Options Summary.).
|
||
|
||
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.
|
||
|
||
|
||
File: make.info, Node: Options Summary, Prev: Testing, Up: Running
|
||
|
||
Summary of Options
|
||
==================
|
||
|
||
Here is a table of all the options `make' understands:
|
||
|
||
`-b'
|
||
`-m'
|
||
These options are ignored for compatibility with other versions of
|
||
`make'.
|
||
|
||
`-C DIR'
|
||
`--directory=DIR'
|
||
Change to directory DIR before reading the makefiles. If multiple
|
||
`-C' options are specified, each is interpreted relative to the
|
||
previous one: `-C / -C etc' is equivalent to `-C /etc'. This is
|
||
typically used with recursive invocations of `make' (*note
|
||
Recursive Use of `make': Recursion.).
|
||
|
||
`-d'
|
||
Print debugging information in addition to normal processing. The
|
||
debugging information says which files are being considered for
|
||
remaking, which file-times are being compared and with what
|
||
results, which files actually need to be remade, which implicit
|
||
rules are considered and which are applied--everything interesting
|
||
about how `make' decides what to do. The `-d' option is
|
||
equivalent to `--debug=a' (see below).
|
||
|
||
`--debug[=OPTIONS]'
|
||
Print debugging information in addition to normal processing.
|
||
Various levels and types of output can be chosen. With no
|
||
arguments, print the "basic" level of debugging. Possible
|
||
arguments are below; only the first character is considered, and
|
||
values must be comma- or space-separated.
|
||
|
||
`a (all)'
|
||
All types of debugging output are enabled. This is
|
||
equivalent to using `-d'.
|
||
|
||
`b (basic)'
|
||
Basic debugging prints each target that was found to be
|
||
out-of-date, and whether the build was successful or not.
|
||
|
||
`v (verbose)'
|
||
A level above `basic'; includes messages about which
|
||
makefiles were parsed, prerequisites that did not need to be
|
||
rebuilt, etc. This option also enables `basic' messages.
|
||
|
||
`i (implicit)'
|
||
Prints messages describing the implicit rule searches for
|
||
each target. This option also enables `basic' messages.
|
||
|
||
`j (jobs)'
|
||
Prints messages giving details on the invocation of specific
|
||
subcommands.
|
||
|
||
`m (makefile)'
|
||
By default, the above messages are not enabled while trying
|
||
to remake the makefiles. This option enables messages while
|
||
rebuilding makefiles, too. Note that the `all' option does
|
||
enable this option. This option also enables `basic'
|
||
messages.
|
||
|
||
`-e'
|
||
`--environment-overrides'
|
||
Give variables taken from the environment precedence over
|
||
variables from makefiles. *Note Variables from the Environment:
|
||
Environment.
|
||
|
||
`-f FILE'
|
||
`--file=FILE'
|
||
`--makefile=FILE'
|
||
Read the file named FILE as a makefile. *Note Writing Makefiles:
|
||
Makefiles.
|
||
|
||
`-h'
|
||
`--help'
|
||
Remind you of the options that `make' understands and then exit.
|
||
|
||
`-i'
|
||
`--ignore-errors'
|
||
Ignore all errors in commands executed to remake files. *Note
|
||
Errors in Commands: Errors.
|
||
|
||
`-I DIR'
|
||
`--include-dir=DIR'
|
||
Specifies a directory DIR to search for included makefiles. *Note
|
||
Including Other Makefiles: Include. If several `-I' options are
|
||
used to specify several directories, the directories are searched
|
||
in the order specified.
|
||
|
||
`-j [JOBS]'
|
||
`--jobs[=JOBS]'
|
||
Specifies the number of jobs (commands) to run simultaneously.
|
||
With no argument, `make' runs as many jobs simultaneously as
|
||
possible. If there is more than one `-j' option, the last one is
|
||
effective. *Note Parallel Execution: Parallel, for more
|
||
information on how commands are run. Note that this option is
|
||
ignored on MS-DOS.
|
||
|
||
`-k'
|
||
`--keep-going'
|
||
Continue as much as possible after an error. While the target that
|
||
failed, and those that depend on it, cannot be remade, the other
|
||
prerequisites of these targets can be processed all the same.
|
||
*Note Testing the Compilation of a Program: Testing.
|
||
|
||
`-l [LOAD]'
|
||
`--load-average[=LOAD]'
|
||
`--max-load[=LOAD]'
|
||
Specifies that no new jobs (commands) should be started if there
|
||
are other jobs running and the load average is at least LOAD (a
|
||
floating-point number). With no argument, removes a previous load
|
||
limit. *Note Parallel Execution: Parallel.
|
||
|
||
`-n'
|
||
`--just-print'
|
||
`--dry-run'
|
||
`--recon'
|
||
Print the commands that would be executed, but do not execute them.
|
||
*Note Instead of Executing the Commands: Instead of Execution.
|
||
|
||
`-o FILE'
|
||
`--old-file=FILE'
|
||
`--assume-old=FILE'
|
||
Do not remake the file FILE even if it is older than its
|
||
prerequisites, and do not remake anything on account of changes in
|
||
FILE. Essentially the file is treated as very old and its rules
|
||
are ignored. *Note Avoiding Recompilation of Some Files: Avoiding
|
||
Compilation.
|
||
|
||
`-p'
|
||
`--print-data-base'
|
||
Print the data base (rules and variable values) that results from
|
||
reading the makefiles; then execute as usual or as otherwise
|
||
specified. This also prints the version information given by the
|
||
`-v' switch (see below). To print the data base without trying to
|
||
remake any files, use `make -qp'. To print the data base of
|
||
predefined rules and variables, use `make -p -f /dev/null'. The
|
||
data base output contains filename and linenumber information for
|
||
command and variable definitions, so it can be a useful debugging
|
||
tool in complex environments.
|
||
|
||
`-q'
|
||
`--question'
|
||
"Question mode". Do not run any commands, or print anything; just
|
||
return an exit status that is zero if the specified targets are
|
||
already up to date, one if any remaking is required, or two if an
|
||
error is encountered. *Note Instead of Executing the Commands:
|
||
Instead of Execution.
|
||
|
||
`-r'
|
||
`--no-builtin-rules'
|
||
Eliminate use of the built-in implicit rules (*note Using Implicit
|
||
Rules: Implicit Rules.). You can still define your own by writing
|
||
pattern rules (*note Defining and Redefining Pattern Rules:
|
||
Pattern Rules.). The `-r' option also clears out the default list
|
||
of suffixes for suffix rules (*note Old-Fashioned Suffix Rules:
|
||
Suffix Rules.). But you can still define your own suffixes with a
|
||
rule for `.SUFFIXES', and then define your own suffix rules. Note
|
||
that only _rules_ are affected by the `-r' option; default
|
||
variables remain in effect (*note Variables Used by Implicit
|
||
Rules: Implicit Variables.); see the `-R' option below.
|
||
|
||
`-R'
|
||
`--no-builtin-variables'
|
||
Eliminate use of the built-in rule-specific variables (*note
|
||
Variables Used by Implicit Rules: Implicit Variables.). You can
|
||
still define your own, of course. The `-R' option also
|
||
automatically enables the `-r' option (see above), since it
|
||
doesn't make sense to have implicit rules without any definitions
|
||
for the variables that they use.
|
||
|
||
`-s'
|
||
`--silent'
|
||
`--quiet'
|
||
Silent operation; do not print the commands as they are executed.
|
||
*Note Command Echoing: Echoing.
|
||
|
||
`-S'
|
||
`--no-keep-going'
|
||
`--stop'
|
||
Cancel the effect of the `-k' option. This is never necessary
|
||
except in a recursive `make' where `-k' might be inherited from
|
||
the top-level `make' via `MAKEFLAGS' (*note Recursive Use of
|
||
`make': Recursion.) or if you set `-k' in `MAKEFLAGS' in your
|
||
environment.
|
||
|
||
`-t'
|
||
`--touch'
|
||
Touch files (mark them up to date without really changing them)
|
||
instead of running their commands. This is used to pretend that
|
||
the commands were done, in order to fool future invocations of
|
||
`make'. *Note Instead of Executing the Commands: Instead of
|
||
Execution.
|
||
|
||
`-v'
|
||
`--version'
|
||
Print the version of the `make' program plus a copyright, a list
|
||
of authors, and a notice that there is no warranty; then exit.
|
||
|
||
`-w'
|
||
`--print-directory'
|
||
Print a message containing the working directory both before and
|
||
after executing the makefile. This may be useful for tracking
|
||
down errors from complicated nests of recursive `make' commands.
|
||
*Note Recursive Use of `make': Recursion. (In practice, you
|
||
rarely need to specify this option since `make' does it for you;
|
||
see *Note The `--print-directory' Option: -w Option.)
|
||
|
||
`--no-print-directory'
|
||
Disable printing of the working directory under `-w'. This option
|
||
is useful when `-w' is turned on automatically, but you do not
|
||
want to see the extra messages. *Note The `--print-directory'
|
||
Option: -w Option.
|
||
|
||
`-W FILE'
|
||
`--what-if=FILE'
|
||
`--new-file=FILE'
|
||
`--assume-new=FILE'
|
||
Pretend that the target FILE has just been modified. When used
|
||
with the `-n' flag, this shows you what would happen if you were
|
||
to modify that file. Without `-n', it is almost the same as
|
||
running a `touch' command on the given file before running `make',
|
||
except that the modification time is changed only in the
|
||
imagination of `make'. *Note Instead of Executing the Commands:
|
||
Instead of Execution.
|
||
|
||
`--warn-undefined-variables'
|
||
Issue a warning message whenever `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.
|
||
|
||
|
||
File: make.info, Node: Implicit Rules, Next: Archives, Prev: Running, Up: Top
|
||
|
||
Using Implicit Rules
|
||
********************
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
You can define your own implicit rules by writing "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.
|
||
|
||
* Menu:
|
||
|
||
* Using Implicit:: How to use an existing implicit rule
|
||
to get the commands for updating a file.
|
||
* Catalogue of Rules:: A list of built-in implicit rules.
|
||
* Implicit Variables:: How to change what predefined rules do.
|
||
* Chained Rules:: How to use a chain of implicit rules.
|
||
* Pattern Rules:: How to define new implicit rules.
|
||
* Last Resort:: How to defining commands for rules
|
||
which cannot find any.
|
||
* Suffix Rules:: The old-fashioned style of implicit rule.
|
||
* Implicit Rule Search:: The precise algorithm for applying
|
||
implicit rules.
|
||
|