mirror of
https://salsa.debian.org/srivasta/make-dfsg.git
synced 2025-02-12 07:07:39 +00:00
1253 lines
49 KiB
Text
1253 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.
|
|||
|
|