mirror of
https://salsa.debian.org/srivasta/make-dfsg.git
synced 2025-02-12 07:07:39 +00:00
Initial upstream version git-archimport-id: srivasta@debian.org--2003-primary/make--upstream--3.0--base-0
1252 lines
49 KiB
Text
1252 lines
49 KiB
Text
This is make.info, produced by makeinfo version 4.2 from make.texi.
|
||
|
||
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.60, last updated 08 July 2002, of `The GNU Make
|
||
Manual', for `make', Version 3.80.
|
||
|
||
Copyright 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,
|
||
1997, 1998, 1999, 2000, 2002 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to copy, distribute and/or modify this document
|
||
under the terms of the GNU Free Documentation License, Version 1.1 or
|
||
any later version published by the Free Software Foundation; with no
|
||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||
Texts. A copy of the license is included in the section entitled "GNU
|
||
Free Documentation License".
|
||
|
||
|
||
File: make.info, Node: Syntax of Functions, Next: Text Functions, Prev: Functions, Up: Functions
|
||
|
||
Function Call Syntax
|
||
====================
|
||
|
||
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.
|
||
|
||
|
||
File: make.info, Node: Text Functions, Next: File Name Functions, Prev: Syntax of Functions, Up: Functions
|
||
|
||
Functions for String Substitution and Analysis
|
||
==============================================
|
||
|
||
Here are some functions that operate on strings:
|
||
|
||
`$(subst FROM,TO,TEXT)'
|
||
Performs a textual replacement on the text TEXT: each occurrence
|
||
of FROM is replaced by TO. The result is substituted for the
|
||
function call. For example,
|
||
|
||
$(subst ee,EE,feet on the street)
|
||
|
||
substitutes the string `fEEt on the strEEt'.
|
||
|
||
`$(patsubst PATTERN,REPLACEMENT,TEXT)'
|
||
Finds whitespace-separated words in TEXT that match PATTERN and
|
||
replaces them with REPLACEMENT. Here PATTERN may contain a `%'
|
||
which acts as a wildcard, matching any number of any characters
|
||
within a word. If REPLACEMENT also contains a `%', the `%' is
|
||
replaced by the text that matched the `%' in PATTERN. Only the
|
||
first `%' in the PATTERN and REPLACEMENT is treated this way; any
|
||
subsequent `%' is unchanged.
|
||
|
||
`%' characters in `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 (*note Substitution References:
|
||
Substitution Refs.) 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.o
|
||
|
||
To 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)'
|
||
Removes leading and trailing whitespace from STRING and replaces
|
||
each internal sequence of one or more whitespace characters with a
|
||
single space. Thus, `$(strip a b c )' results in `a b c'.
|
||
|
||
The function `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 (*note Conditionals::).
|
||
|
||
Thus, the following may fail to have the desired results:
|
||
|
||
.PHONY: all
|
||
ifneq "$(needs_made)" ""
|
||
all: $(needs_made)
|
||
else
|
||
all:;@echo 'Nothing to make!'
|
||
endif
|
||
|
||
Replacing the variable reference `$(needs_made)' with the function
|
||
call `$(strip $(needs_made))' in the `ifneq' directive would make
|
||
it more robust.
|
||
|
||
`$(findstring FIND,IN)'
|
||
Searches IN for an occurrence of FIND. If it occurs, the value is
|
||
FIND; otherwise, the value is empty. You can use this function in
|
||
a conditional to test for the presence of a specific substring in
|
||
a given string. Thus, the two examples,
|
||
|
||
$(findstring a,a b c)
|
||
$(findstring a,b c)
|
||
|
||
produce the values `a' and `' (the empty string), respectively.
|
||
*Note Testing Flags::, for a practical application of `findstring'.
|
||
|
||
`$(filter PATTERN...,TEXT)'
|
||
Returns all whitespace-separated words in TEXT that _do_ match any
|
||
of the PATTERN words, removing any words that _do not_ match. The
|
||
patterns are written using `%', just like the patterns used in the
|
||
`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 foo
|
||
|
||
says 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)'
|
||
Returns all whitespace-separated words in TEXT that _do not_ match
|
||
any of the PATTERN words, removing the words that _do_ match one
|
||
or more. 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.o
|
||
|
||
the following generates a list which contains all the object files
|
||
not in `mains':
|
||
|
||
$(filter-out $(mains),$(objects))
|
||
|
||
`$(sort LIST)'
|
||
Sorts the words of LIST in lexical order, removing duplicate
|
||
words. The output is a list of words separated by single spaces.
|
||
Thus,
|
||
|
||
$(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.
|
||
|
||
`$(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.
|
||
|
||
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 (*note
|
||
`VPATH' Search Path for All Prerequisites: General Search.). 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 (*note The `override' Directive:
|
||
Override Directive.).
|
||
|
||
|
||
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.
|
||
|
||
`$(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: Value 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 $(addsuffix /$(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: Value Function, Next: Eval Function, Prev: Call Function, Up: Functions
|
||
|
||
The `value' Function
|
||
====================
|
||
|
||
The `value' function provides a way for you to use the value of a
|
||
variable _without_ having it expanded. Please note that this does not
|
||
undo expansions which have already occurred; for example if you create
|
||
a simply expanded variable its value is expanded during the definition;
|
||
in that case the `value' function will return the same result as using
|
||
the variable directly.
|
||
|
||
The syntax of the `value' function is:
|
||
|
||
$(value VARIABLE)
|
||
|
||
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.)
|
||
|
||
The result of this function is a string containing the value of
|
||
VARIABLE, without any expansion occurring. For example, in this
|
||
makefile:
|
||
|
||
FOO = $PATH
|
||
|
||
all:
|
||
@echo $(FOO)
|
||
@echo $(value FOO)
|
||
|
||
The first output line would be `ATH', since the "$P" would be expanded
|
||
as a `make' variable, while the second output line would be the current
|
||
value of your `$PATH' environment variable, since the `value' function
|
||
avoided the expansion.
|
||
|
||
The `value' function is most often used in conjunction with the
|
||
`eval' function (*note Eval Function::).
|
||
|
||
|
||
File: make.info, Node: Eval Function, Next: Origin Function, Prev: Value Function, Up: Functions
|
||
|
||
The `eval' Function
|
||
===================
|
||
|
||
The `eval' function is very special: it allows you to define new
|
||
makefile constructs that are not constant; which are the result of
|
||
evaluating other variables and functions. The argument to the `eval'
|
||
function is expanded, then the results of that expansion are parsed as
|
||
makefile syntax. The expanded results can define new `make' variables,
|
||
targets, implicit or explicit rules, etc.
|
||
|
||
The result of the `eval' function is always the empty string; thus,
|
||
it can be placed virtually anywhere in a makefile without causing
|
||
syntax errors.
|
||
|
||
It's important to realize that the `eval' argument is expanded
|
||
_twice_; first by the `eval' function, then the results of that
|
||
expansion are expanded again when they are parsed as makefile syntax.
|
||
This means you may need to provide extra levels of escaping for "$"
|
||
characters when using `eval'. The `value' function (*note Value
|
||
Function::) can sometimes be useful in these situations, to circumvent
|
||
unwanted expansions.
|
||
|
||
Here is an example of how `eval' can be used; this example combines
|
||
a number of concepts and other functions. Although it might seem
|
||
overly complex to use `eval' in this example, rather than just writing
|
||
out the rules, consider two things: first, the template definition (in
|
||
`PROGRAM_template') could need to be much more complex than it is here;
|
||
and second, you might put the complex, "generic" part of this example
|
||
into another makefile, then include it in all the individual makefiles.
|
||
Now your individual makefiles are quite straightforward.
|
||
|
||
PROGRAMS = server client
|
||
|
||
server_OBJS = server.o server_priv.o server_access.o
|
||
server_LIBS = priv protocol
|
||
|
||
client_OBJS = client.o client_api.o client_mem.o
|
||
client_LIBS = protocol
|
||
|
||
# Everything after this is generic
|
||
|
||
.PHONY: all
|
||
all: $(PROGRAMS)
|
||
|
||
define PROGRAM_template
|
||
$(1): $$($(1)_OBJ) $$($(1)_LIBS:%=-l%)
|
||
ALL_OBJS += $$($(1)_OBJS)
|
||
endef
|
||
|
||
$(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog))))
|
||
|
||
$(PROGRAMS):
|
||
$(LINK.o) $^ $(LDLIBS) -o $@
|
||
|
||
clean:
|
||
rm -f $(ALL_OBJS) $(PROGRAMS)
|
||
|
||
|
||
File: make.info, Node: Origin Function, Next: Shell Function, Prev: Eval 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 (*note How `make' Reads a Makefile: Reading
|
||
Makefiles.). Because this function involves spawning a new shell, you
|
||
should carefully consider the performance implications of using the
|
||
`shell' function within recursively expanded variables vs. simply
|
||
expanded variables (*note The Two Flavors of Variables: Flavors.).
|
||
|
||
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, Prev: Running, 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, ensuring that the object files are up-to-date
|
||
before you begin.
|
||
|
||
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 also 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.
|
||
|