-d Display the reasons why make chooses to
rebuild a target; make displays any and all
dependencies that are newer. In addition,
make displays options read in from the
MAKEFLAGS environment variable.
|
Comment line syntax is the same as tcl, which means that a trailing '' will make next line comment too. |
Help
http://www.gnu.org/software/autoconf/manual/make/
Useful parameters
-dd Display the dependency check and processing
in vast detail.
-n No execution mode. Print commands, but do
not execute them.
-p Print out the complete set of macro defini-
tions and target descriptions.
-p Print the data base (rules and variable values) that results
from reading the makefiles; then execute as usual or as other-
wise specified. This also prints the version information given
by the -v switch (see below). To print the data base without
trying to remake any files, use make -p -f/dev/null.
-P Merely report dependencies, rather than
building them.
-W file
Pretend that the target file has just been modified. When used with the -n flag, this shows you what would happen if you were to modify that file. Without -n, it is almost the same as run- ning a touch command on the given file before running make, except that the modification time is changed only in the imagi- nation of make.
|
|
-P not recognized by our GNU make, working copy. |
`MAKE' Variable
Recursive `make' commands should always use the variable `MAKE', not the explicit command name `make', as shown here:
subsystem:
cd subdir && $(MAKE)
The value of this variable is the file name with which `make' was invoked. If this file name was `/bin/make', then the command executed is `cd subdir && /bin/make'. If you use a special version of `make' to run the top-level makefile, the same special version will be executed for recursive invocations.
automatic variables (Dynamic Macros)
Implicit Rules -> Pattern Rules -> Automatic Variables
Here is a table of automatic variables:
`$@'
The file name of the target of the rule. If the target is an
archive member, then `$@' is the name of the archive file. In a
pattern rule that has multiple targets (*note Introduction to
Pattern Rules: Pattern Intro.), `$@' is the name of whichever
target caused the rule's commands to be run.
`$%'
The target member name, when the target is an archive member.
*Note Archives::. For example, if the target is `foo.a(bar.o)'
then `$%' is `bar.o' and `$@' is `foo.a'. `$%' is empty when the
target is not an archive member.
`$<'
The name of the first prerequisite. If the target got its
commands from an implicit rule, this will be the first
prerequisite added by the implicit rule (*note Implicit Rules::.).
`$?'
The names of all the prerequisites that are newer than the target,
with spaces between them. For prerequisites which are archive
members, only the member named is used (*note Archives::.).
`$^'
The names of all the prerequisites, with spaces between them. For
prerequisites which are archive members, only the member named is
used (*note Archives::.). A target has only one prerequisite on
each other file it depends on, no matter how many times each file
is listed as a prerequisite. So if you list a prerequisite more
than once for a target, the value of `$^' contains just one copy
of the name.
`$+'
This is like `$^', but prerequisites listed more than once are
duplicated in the order they were listed in the makefile. This is
primarily useful for use in linking commands where it is
meaningful to repeat library file names in a particular order.
`$*'
The stem with which an implicit rule matches (*note How Patterns
Match: Pattern Match.). If the target is `dir/a.foo.b' and the
target pattern is `a.%.b' then the stem is `dir/foo'. The stem is
useful for constructing names of related files.
In a static pattern rule, the stem is part of the file name that matched the `%' in the target pattern.
In an explicit rule, there is no stem; so `$*' cannot be determined in that way. Instead, if the target name ends with a recognized suffix (*note Old-Fashioned Suffix Rules: Suffix Rules.), `$*' is set to the target name minus the suffix. For example, if the target name is `foo.c', then `$*' is set to `foo', since `.c' is a suffix. GNU `make' does this bizarre thing only for compatibility with other implementations of `make'. You should generally avoid using `$*' except in implicit rules or static pattern rules.
If the target name in an explicit rule does not end with a recognized suffix, `$*' is set to the empty string for that rule.
For your convenience, GNU `make' sets the variable `CURDIR' to the pathname of the current working directory for you. If `-C' is in effect, it will contain the path of the new directory, not the original.
Two Flavors of Variables
There are two ways that a variable in GNU `make' can have a value; we call them the two "flavors" of variables. The two flavors are distinguished in how they are defined and in what they do when expanded.
=<<, >>
The first flavor of variable is a "recursively expanded" variable. Variables of this sort are defined by lines using `=' (*note Setting Variables: Setting.) or by the `define' directive (*note Defining Variables Verbatim: Defining.). The value you specify is installed verbatim; if it contains references to other variables, these references are expanded whenever this variable is substituted (in the course of expanding some other string). When this happens, it is called "recursive expansion".
For example,
foo = $(bar) bar = $(ugh) ugh = Huh?
all:;echo $(foo)
will echo `Huh?': `$(foo)' expands to `$(bar)' which expands to `$(ugh)' which finally expands to `Huh?'.
This flavor of variable is the only sort supported by other versions of `make'. It has its advantages and its disadvantages. An advantage (most would say) is that:
CFLAGS = $(include_dirs) -O include_dirs = -Ifoo -Ibar
will do what was intended: when `CFLAGS' is expanded in a command, it will expand to `-Ifoo -Ibar -O'. A major disadvantage is that you cannot append something on the end of a variable, as in
CFLAGS = $(CFLAGS) -O
because it will cause an infinite loop in the variable expansion. (Actually `make' detects the infinite loop and reports an error.)
Another disadvantage is that any functions (*note Functions for Transforming Text: Functions.) referenced in the definition will be executed every time the variable is expanded. This makes `make' run slower; worse, it causes the `wildcard' and `shell' functions to give unpredictable results because you cannot easily control when they are called, or even how many times.
:=<<, >>
To avoid all the problems and inconveniences of recursively expanded variables, there is another flavor: simply expanded variables.
"Simply expanded variables" are defined by lines using `:=' (*note Setting Variables: Setting.). The value of a simply expanded variable is scanned once and for all, expanding any references to other variables and functions, when the variable is defined. The actual value of the simply expanded variable is the result of expanding the text that you write. It does not contain any references to other variables; it contains their values _as of the time this variable was defined_. Therefore,
x := foo y := $(x) bar x := later
is equivalent to
y := foo bar x := later
When a simply expanded variable is referenced, its value is substituted verbatim.
Here is a somewhat more complicated example, illustrating the use of `:=' in conjunction with the `shell' function. (*Note The `shell' Function: Shell Function.) This example also shows use of the variable `MAKELEVEL', which is changed when it is passed down from level to level. (*Note Communicating Variables to a Sub-`make': Variables/Recursion, for information about `MAKELEVEL'.)
ifeq (0,${MAKELEVEL})
cur-dir := $(shell pwd)
whoami := $(shell whoami)
host-type := $(shell arch)
MAKE := ${MAKE} host-type=${host-type} whoami=${whoami}
endif
An advantage of this use of `:=' is that a typical `descend into a directory' command then looks like this:
${subdirs}:
${MAKE} cur-dir=${cur-dir}/$@ -C $@ all
Simply expanded variables generally make complicated makefile programming more predictable because they work like variables in most programming languages. They allow you to redefine a variable using its own value (or its value processed in some way by one of the expansion functions) and to use the expansion functions much more efficiently (*note Functions for Transforming Text: Functions.).
Spaces
-
Leading whitespace characters are discarded from your input before substitution of variable references and function calls
-
trailing space characters are _not_ stripped from variable values
You can also use them to introduce controlled leading whitespace into variable values. Leading whitespace characters are discarded from your input before substitution of variable references and function calls; this means you can include leading spaces in a variable value by protecting them with variable references, like this:
nullstring := space := $(nullstring) # end of the line
Here the value of the variable `space' is precisely one space. The comment `# end of the line' is included here just for clarity. Since trailing space characters are _not_ stripped from variable values, just a space at the end of the line would have the same effect (but be rather hard to read). If you put whitespace at the end of a variable value, it is a good idea to put a comment like that at the end of the line to make your intent clear. Conversely, if you do _not_ want any whitespace characters at the end of your variable value, you must remember not to put a random comment on the end of the line after some whitespace, such as this:
dir := /foo/bar # directory to put the frobs in
Here the value of the variable `dir' is `/foo/bar ' (with four trailing spaces), which was probably not the intention. (Imagine something like `$(dir)/file' with this definition!)
?=<<, >>
There is another assignment operator for variables, `?='. This is called a conditional variable assignment operator, because it only has an effect if the variable is not yet defined. This statement:
FOO ?= bar
is exactly equivalent to this (*note The `origin' Function: Origin Function.):
ifeq ($(origin FOO), undefined) FOO = bar endif
Note that a variable set to an empty value is still defined, so `?=' will not set that variable.
Syntax of Conditionals
CONDITIONAL-DIRECTIVE TEXT-IF-TRUE endif
The TEXT-IF-TRUE may be any lines of text, to be considered as part of the makefile if the condition is true. If the condition is false, no text is used instead.
Or,
CONDITIONAL-DIRECTIVE TEXT-IF-TRUE else TEXT-IF-FALSE endif
There are four different directives that test different conditions.
`ifeq (ARG1, ARG2)'
Expand all variable references in ARG1 and ARG2 and compare them. If they are identical, the TEXT-IF-TRUE is effective; otherwise, the TEXT-IF-FALSE, if any, is effective.
Often you want to test if a variable has a non-empty value. When the value results from complex expansions of variables and functions, expansions you would consider empty may actually contain whitespace characters and thus are not seen as empty. However, you can use the `strip' function (*note Text Functions::) to avoid interpreting whitespace as a non-empty value. For example:
ifeq ($(strip $(foo)),) TEXT-IF-EMPTY endif
will evaluate TEXT-IF-EMPTY even if the expansion of `$(foo)' contains whitespace characters.
`ifneq (ARG1, ARG2)'
Expand all variable references in ARG1 and ARG2 and compare them. If they are different, the TEXT-IF-TRUE is effective; otherwise, the TEXT-IF-FALSE, if any, is effective.
`ifdef VARIABLE-NAME'
If the variable VARIABLE-NAME has a non-empty value, the TEXT-IF-TRUE is effective; otherwise, the TEXT-IF-FALSE, if any, is effective. Variables that have never been defined have an empty value.
Note that `ifdef' only tests whether a variable has a value. It does not expand the variable to see if that value is nonempty. Consequently, tests using `ifdef' return true for all definitions except those like `foo ='. To test for an empty value, use `ifeq ($(foo),)'. For example,
bar = foo = $(bar) ifdef foo frobozz = yes else frobozz = no endif
sets `frobozz' to `yes', while:
foo = ifdef foo frobozz = yes else frobozz = no endif
sets `frobozz' to `no'.
`ifndef VARIABLE-NAME' If the variable VARIABLE-NAME has an empty value, the TEXT-IF-TRUE is effective; otherwise, the TEXT-IF-FALSE, if any, is effective.
Introduction to Pattern Rules
A pattern rule contains the character `%' (exactly one of them) in the target; otherwise, it looks exactly like an ordinary rule. The target is a pattern for matching file names; the `%' matches any nonempty substring, while other characters match only themselves.
For example, `%.c' as a pattern matches any file name that ends in `.c'. `s.%.c' as a pattern matches any file name that starts with `s.', ends in `.c' and is at least five characters long. (There must be at least one character to match the `%'.) The substring that the `%' matches is called the "stem".
`%' in a prerequisite of a pattern rule stands for the same stem that was matched by the `%' in the target. In order for the pattern rule to apply, its target pattern must match the file name under consideration, and its prerequisite patterns must name files that exist or can be made. These files become prerequisites of the target.
Thus, a rule of the form
%.o : %.c ; COMMAND...
specifies how to make a file `N.o', with another file `N.c' as its prerequisite, provided that `N.c' exists or can be made.
-- No need to specify .SUFFIX
wildcards
hpp_files=$(wildcard *.hpp)
substitution
substitution variable
sources = foo.c bar.c
include $(sources:.c=.d)
This example uses a substitution variable reference to translate the list of source files `foo.c bar.c' into a list of prerequisite makefiles, `foo.d bar.d'.
subst
%.dvi: %.tex %.chk
# no extension: in case for bibtex
$(LATEX) $(subst .chk,,$<)
Multiple Dependant
%.ps : %.dvi %.chk
$(DVIPS) -o $@ $<
-
$< represent the first dependant (.dvi here).
-
It also fails if rules don't specify how to make .chk
%.dvi: %.tex %.chk # no extension: in case for bibtex $(LATEX) $(subst .chk,,$<)
Automatically Prerequisites Generation
In the makefile for a program, many of the rules you need to write often say only that some object file depends on some header file. For example, if `main.c' uses `defs.h' via an `#include', you would write:
main.o: defs.h
You need this rule so that `make' knows that it must remake `main.o' whenever `defs.h' changes. You can see that for a large program you would have to write dozens of such rules in your makefile. And, you must always be very careful to update the makefile every time you add or remove an `#include'.
To avoid this hassle, most modern C compilers can write these rules for you, by looking at the `#include' lines in the source files. Usually this is done with the `-M' option to the compiler. For example, the command:
cc -M main.c
generates the output:
main.o : main.c defs.h
Thus you no longer have to write all those rules yourself. The compiler will do it for you.
With old `make' programs, it was traditional practice to use this compiler feature to generate prerequisites on demand with a command like `make depend'. That command would create a file `depend' containing all the automatically-generated prerequisites; then the makefile could use `include' to read them in (*note Include::).
In GNU `make', you need never tell `make' explicitly to regenerate the prerequisites, because it always regenerates any makefile that is out of date.
The practice we recommend for automatic prerequisite generation is to have one makefile corresponding to each source file. For each source file `NAME.c' there is a makefile `NAME.d' which lists what files the object file `NAME.o' depends on. That way only the source files that have changed need to be rescanned to produce the new prerequisites.
Here is the pattern rule to generate a file of prerequisites (i.e., a makefile) called `NAME.d' from a C source file called `NAME.c':
%.d: %.c
set -e; $(CC) -M $(CPPFLAGS) $< \
| sed 's/\($*\)\.o[ :]*/\1.o $@ : /g' > $@; \
[ -s $@ ] || rm -f $@
*Note Pattern Rules::, for information on defining pattern rules. The `-e' flag to the shell makes it exit immediately if the `$(CC)' command fails (exits with a nonzero status). Normally the shell exits with the status of the last command in the pipeline (`sed' in this case), so `make' would not notice a nonzero status from the compiler.
With the GNU C compiler, you may wish to use the `-MM' flag instead of `-M'. This omits prerequisites on system header files. *Note Options Controlling the Preprocessor: (gcc.info)Preprocessor Options, for details.
The purpose of the `sed' command is to translate (for example):
main.o : main.c defs.h
into:
main.o main.d : main.c defs.h
This makes each `.d' file depend on all the source and header files that the corresponding `.o' file depends on. `make' then knows it must regenerate the prerequisites whenever any of the source or header files changes.
Once you've defined the rule to remake the `.d' files, you then use the `include' directive to read them all in. *Note Include::. For example:
sources = foo.c bar.c
include $(sources:.c=.d)
(This example uses a substitution variable reference to translate the list of source files `foo.c bar.c' into a list of prerequisite makefiles, `foo.d bar.d'. *Note Substitution Refs::, for full information on substitution references.) Since the `.d' files are makefiles like any others, `make' will remake them as necessary with no further work from you. *Note Remaking Makefiles::.
Speed up
If your machine has 16 or more Megabytes of RAM, there is a useful speed-up that can be done, which is to permit the kernel to compile two or modules in parallel. This will increase the load on the machine whilst the kernel is being recompiled, but will reduce the time during which the compilation will be taking place.
Experience has shown that the optimum value depends on the amount of RAM in your system according to the following formula, at least for systems with up to 32 Megabytes of RAM, although it may be a little conservative for systems with larger amounts of RAM:
N = [RAM in Megabytes] / 8 + 1
When you have decided on the correct number, edit the file /usr/src/linux/Makefile and find the line that currently reads:
MAKE=make
Replace it with one reading:
MAKE=make -j N
where N is the number determined above.
Phony Targets
http://www.gnu.org/software/autoconf/manual/make/Phony-Targets.html
A phony target is one that is not really the name of a file. It is just a name for some commands to be executed when you make an explicit request. There are two reasons to use a phony target: to avoid a conflict with a file of the same name, and to improve performance.
If you write a rule whose commands will not create the target file, the commands will be executed every time the target comes up for remaking. Here is an example:
clean:
rm *.o temp
Because the `rm' command does not create a file named `clean', probably no such file will ever exist. Therefore, the `rm' command will be executed every time you say `make clean'. The phony target will cease to work if anything ever does create a file named clean in this directory. Since it has no prerequisites, the file clean would inevitably be considered up to date, and its commands would not be executed. To avoid this problem, you can explicitly declare the target to be phony, using the special target .PHONY (see Special Built-in Target Names) as follows:
.PHONY : clean
Once this is done, `make clean' will run the commands regardless of whether there is a file named clean.
When one phony target is a prerequisite of another, it serves as a subroutine of the other. For example, here `make cleanall' will delete the object files, the difference files, and the file program:
.PHONY: cleanall cleanobj cleandiff
cleanall : cleanobj cleandiff
rm program
cleanobj :
rm *.o
cleandiff :
rm *.diff
Force Targets
http://www.gnu.org/software/autoconf/manual/make/Force-Targets.html
If a rule has no prerequisites or commands, and the target of the rule is a nonexistent file, then make imagines this target to have been updated whenever its rule is run. This implies that all targets depending on this one will always have their commands run.
An example will illustrate this:
clean: FORCE
rm $(objects)
FORCE:
Here the target `FORCE' satisfies the special conditions, so the target clean that depends on it is forced to run its commands. There is nothing special about the name `FORCE', but that is one name commonly used this way.
As you can see, using `FORCE' this way has the same results as using
.PHONY: clean
Using `.PHONY' is more explicit and more efficient. However, other versions of make do not support `.PHONY'; thus `FORCE' appears in many makefiles.
Empty Target Files
http://www.gnu.org/software/autoconf/manual/make/Empty-Targets.html
When you ask to remake the empty target, the commands are executed if any prerequisite is more recent than the target; in other words, if a prerequisite has changed since the last time you remade the target. Here is an example:
print: foo.c bar.c
lpr -p $?
touch print
With this rule, `make print' will execute the lpr command if either source file has changed since the last `make print'. The automatic variable `$?' is used to print only those files that have changed.
What Name to Give Your Makefile
*Tags*: gnu make makefile file name order
make looks for the makefile in order: `GNUmakefile', `makefile' and `Makefile'.
Normally you should call your makefile either `makefile' or `Makefile'. (We recommend `Makefile' because it appears prominently near the beginning of a directory listing, right near other important files such as `README'.) The first name checked, `GNUmakefile', is not recommended for most makefiles.
If you want to use a nonstandard name for your makefile, you can specify the makefile name with the `-f' or `—file' option. You can specify several makefiles using more than one `-f' or `—file' option. All the makefiles are effectively concatenated in the order specified.
