|
|
This is make.info, produced by makeinfo version 5.2 from make.texi.
|
|
|
|
|
|
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.74, last updated 21 May 2016, of 'The GNU Make
|
|
|
Manual', for GNU 'make' version 4.2.1.
|
|
|
|
|
|
Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,
|
|
|
1997, 1998, 1999, 2000, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
|
|
|
2010, 2011, 2012, 2013, 2014, 2015, 2016 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.3 or any later version published by the Free Software
|
|
|
Foundation; with no Invariant Sections, with the Front-Cover Texts
|
|
|
being "A GNU Manual," and with the Back-Cover Texts as in (a)
|
|
|
below. A copy of the license is included in the section entitled
|
|
|
"GNU Free Documentation License."
|
|
|
|
|
|
(a) The FSF's Back-Cover Text is: "You have the freedom to copy and
|
|
|
modify this GNU manual. Buying copies from the FSF supports it in
|
|
|
developing GNU and promoting software freedom."
|
|
|
INFO-DIR-SECTION Software development
|
|
|
START-INFO-DIR-ENTRY
|
|
|
* Make: (make). Remake files automatically.
|
|
|
END-INFO-DIR-ENTRY
|
|
|
|
|
|
|
|
|
File: make.info, Node: Implicit Rules, Next: Archives, Prev: Running, Up: Top
|
|
|
|
|
|
10 Using Implicit Rules
|
|
|
***********************
|
|
|
|
|
|
Certain standard ways of remaking target files are used very often. For
|
|
|
example, one customary way to make an object file is from a C source
|
|
|
file using the C compiler, 'cc'.
|
|
|
|
|
|
"Implicit rules" tell 'make' how to use customary techniques so that
|
|
|
you do not have to specify them in detail when you want to use them.
|
|
|
For example, there is an implicit rule for C compilation. File names
|
|
|
determine which implicit rules are run. For example, C compilation
|
|
|
typically takes a '.c' file and makes a '.o' file. So 'make' applies
|
|
|
the implicit rule for C compilation when it sees this combination of
|
|
|
file name endings.
|
|
|
|
|
|
A chain of implicit rules can apply in sequence; for example, 'make'
|
|
|
will remake a '.o' file from a '.y' file by way of a '.c' file.
|
|
|
|
|
|
The built-in implicit rules use several variables in their recipes so
|
|
|
that, by changing the values of the variables, you can change the way
|
|
|
the implicit rule works. For example, the variable 'CFLAGS' controls
|
|
|
the flags given to the C compiler by the implicit rule for C
|
|
|
compilation.
|
|
|
|
|
|
You can define your own implicit rules by writing "pattern rules".
|
|
|
|
|
|
"Suffix rules" are a more limited way to define implicit rules.
|
|
|
Pattern rules are more general and clearer, but suffix rules are
|
|
|
retained for compatibility.
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* Using Implicit:: How to use an existing implicit rule
|
|
|
to get the recipes for updating a file.
|
|
|
* Catalogue of Rules:: A list of built-in rules.
|
|
|
* Implicit Variables:: How to change what predefined rules do.
|
|
|
* Chained Rules:: How to use a chain of implicit rules.
|
|
|
* Pattern Rules:: How to define new implicit rules.
|
|
|
* Last Resort:: How to define a recipe for rules which
|
|
|
cannot find any.
|
|
|
* Suffix Rules:: The old-fashioned style of implicit rule.
|
|
|
* Implicit Rule Search:: The precise algorithm for applying
|
|
|
implicit rules.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Using Implicit, Next: Catalogue of Rules, Prev: Implicit Rules, Up: Implicit Rules
|
|
|
|
|
|
10.1 Using Implicit Rules
|
|
|
=========================
|
|
|
|
|
|
To allow 'make' to find a customary method for updating a target file,
|
|
|
all you have to do is refrain from specifying recipes yourself. Either
|
|
|
write a rule with no recipe, or don't write a rule at all. Then 'make'
|
|
|
will figure out which implicit rule to use based on which kind of source
|
|
|
file exists or can be made.
|
|
|
|
|
|
For example, suppose the makefile looks like this:
|
|
|
|
|
|
foo : foo.o bar.o
|
|
|
cc -o foo foo.o bar.o $(CFLAGS) $(LDFLAGS)
|
|
|
|
|
|
Because you mention 'foo.o' but do not give a rule for it, 'make' will
|
|
|
automatically look for an implicit rule that tells how to update it.
|
|
|
This happens whether or not the file 'foo.o' currently exists.
|
|
|
|
|
|
If an implicit rule is found, it can supply both a recipe and one or
|
|
|
more prerequisites (the source files). You would want to write a rule
|
|
|
for 'foo.o' with no recipe if you need to specify additional
|
|
|
prerequisites, such as header files, that the implicit rule cannot
|
|
|
supply.
|
|
|
|
|
|
Each implicit rule has a target pattern and prerequisite patterns.
|
|
|
There may be many implicit rules with the same target pattern. For
|
|
|
example, numerous rules make '.o' files: one, from a '.c' file with the
|
|
|
C compiler; another, from a '.p' file with the Pascal compiler; and so
|
|
|
on. The rule that actually applies is the one whose prerequisites exist
|
|
|
or can be made. So, if you have a file 'foo.c', 'make' will run the C
|
|
|
compiler; otherwise, if you have a file 'foo.p', 'make' will run the
|
|
|
Pascal compiler; and so on.
|
|
|
|
|
|
Of course, when you write the makefile, you know which implicit rule
|
|
|
you want 'make' to use, and you know it will choose that one because you
|
|
|
know which possible prerequisite files are supposed to exist. *Note
|
|
|
Catalogue of Built-In Rules: Catalogue of Rules, for a catalogue of all
|
|
|
the predefined implicit rules.
|
|
|
|
|
|
Above, we said an implicit rule applies if the required prerequisites
|
|
|
"exist or can be made". A file "can be made" if it is mentioned
|
|
|
explicitly in the makefile as a target or a prerequisite, or if an
|
|
|
implicit rule can be recursively found for how to make it. When an
|
|
|
implicit prerequisite is the result of another implicit rule, we say
|
|
|
that "chaining" is occurring. *Note Chains of Implicit Rules: Chained
|
|
|
Rules.
|
|
|
|
|
|
In general, 'make' searches for an implicit rule for each target, and
|
|
|
for each double-colon rule, that has no recipe. A file that is
|
|
|
mentioned only as a prerequisite is considered a target whose rule
|
|
|
specifies nothing, so implicit rule search happens for it. *Note
|
|
|
Implicit Rule Search Algorithm: Implicit Rule Search, for the details of
|
|
|
how the search is done.
|
|
|
|
|
|
Note that explicit prerequisites do not influence implicit rule
|
|
|
search. For example, consider this explicit rule:
|
|
|
|
|
|
foo.o: foo.p
|
|
|
|
|
|
The prerequisite on 'foo.p' does not necessarily mean that 'make' will
|
|
|
remake 'foo.o' according to the implicit rule to make an object file, a
|
|
|
'.o' file, from a Pascal source file, a '.p' file. For example, if
|
|
|
'foo.c' also exists, the implicit rule to make an object file from a C
|
|
|
source file is used instead, because it appears before the Pascal rule
|
|
|
in the list of predefined implicit rules (*note Catalogue of Built-In
|
|
|
Rules: Catalogue of Rules.).
|
|
|
|
|
|
If you do not want an implicit rule to be used for a target that has
|
|
|
no recipe, you can give that target an empty recipe by writing a
|
|
|
semicolon (*note Defining Empty Recipes: Empty Recipes.).
|
|
|
|
|
|
|
|
|
File: make.info, Node: Catalogue of Rules, Next: Implicit Variables, Prev: Using Implicit, Up: Implicit Rules
|
|
|
|
|
|
10.2 Catalogue of Built-In Rules
|
|
|
================================
|
|
|
|
|
|
Here is a catalogue of predefined implicit rules which are always
|
|
|
available unless the makefile explicitly overrides or cancels them.
|
|
|
*Note Canceling Implicit Rules: Canceling Rules, for information on
|
|
|
canceling or overriding an implicit rule. The '-r' or
|
|
|
'--no-builtin-rules' option cancels all predefined rules.
|
|
|
|
|
|
This manual only documents the default rules available on POSIX-based
|
|
|
operating systems. Other operating systems, such as VMS, Windows, OS/2,
|
|
|
etc. may have different sets of default rules. To see the full list of
|
|
|
default rules and variables available in your version of GNU 'make', run
|
|
|
'make -p' in a directory with no makefile.
|
|
|
|
|
|
Not all of these rules will always be defined, even when the '-r'
|
|
|
option is not given. Many of the predefined implicit rules are
|
|
|
implemented in 'make' as suffix rules, so which ones will be defined
|
|
|
depends on the "suffix list" (the list of prerequisites of the special
|
|
|
target '.SUFFIXES'). The default suffix list is: '.out', '.a', '.ln',
|
|
|
'.o', '.c', '.cc', '.C', '.cpp', '.p', '.f', '.F', '.m', '.r', '.y',
|
|
|
'.l', '.ym', '.lm', '.s', '.S', '.mod', '.sym', '.def', '.h', '.info',
|
|
|
'.dvi', '.tex', '.texinfo', '.texi', '.txinfo', '.w', '.ch' '.web',
|
|
|
'.sh', '.elc', '.el'. All of the implicit rules described below whose
|
|
|
prerequisites have one of these suffixes are actually suffix rules. If
|
|
|
you modify the suffix list, the only predefined suffix rules in effect
|
|
|
will be those named by one or two of the suffixes that are on the list
|
|
|
you specify; rules whose suffixes fail to be on the list are disabled.
|
|
|
*Note Old-Fashioned Suffix Rules: Suffix Rules, for full details on
|
|
|
suffix rules.
|
|
|
|
|
|
Compiling C programs
|
|
|
'N.o' is made automatically from 'N.c' with a recipe of the form
|
|
|
'$(CC) $(CPPFLAGS) $(CFLAGS) -c'.
|
|
|
|
|
|
Compiling C++ programs
|
|
|
'N.o' is made automatically from 'N.cc', 'N.cpp', or 'N.C' with a
|
|
|
recipe of the form '$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c'. We
|
|
|
encourage you to use the suffix '.cc' for C++ source files instead
|
|
|
of '.C'.
|
|
|
|
|
|
Compiling Pascal programs
|
|
|
'N.o' is made automatically from 'N.p' with the recipe '$(PC)
|
|
|
$(PFLAGS) -c'.
|
|
|
|
|
|
Compiling Fortran and Ratfor programs
|
|
|
'N.o' is made automatically from 'N.r', 'N.F' or 'N.f' by running
|
|
|
the Fortran compiler. The precise recipe used is as follows:
|
|
|
|
|
|
'.f'
|
|
|
'$(FC) $(FFLAGS) -c'.
|
|
|
'.F'
|
|
|
'$(FC) $(FFLAGS) $(CPPFLAGS) -c'.
|
|
|
'.r'
|
|
|
'$(FC) $(FFLAGS) $(RFLAGS) -c'.
|
|
|
|
|
|
Preprocessing Fortran and Ratfor programs
|
|
|
'N.f' is made automatically from 'N.r' or 'N.F'. This rule runs
|
|
|
just the preprocessor to convert a Ratfor or preprocessable Fortran
|
|
|
program into a strict Fortran program. The precise recipe used is
|
|
|
as follows:
|
|
|
|
|
|
'.F'
|
|
|
'$(FC) $(CPPFLAGS) $(FFLAGS) -F'.
|
|
|
'.r'
|
|
|
'$(FC) $(FFLAGS) $(RFLAGS) -F'.
|
|
|
|
|
|
Compiling Modula-2 programs
|
|
|
'N.sym' is made from 'N.def' with a recipe of the form '$(M2C)
|
|
|
$(M2FLAGS) $(DEFFLAGS)'. 'N.o' is made from 'N.mod'; the form is:
|
|
|
'$(M2C) $(M2FLAGS) $(MODFLAGS)'.
|
|
|
|
|
|
Assembling and preprocessing assembler programs
|
|
|
'N.o' is made automatically from 'N.s' by running the assembler,
|
|
|
'as'. The precise recipe is '$(AS) $(ASFLAGS)'.
|
|
|
|
|
|
'N.s' is made automatically from 'N.S' by running the C
|
|
|
preprocessor, 'cpp'. The precise recipe is '$(CPP) $(CPPFLAGS)'.
|
|
|
|
|
|
Linking a single object file
|
|
|
'N' is made automatically from 'N.o' by running the linker (usually
|
|
|
called 'ld') via the C compiler. The precise recipe used is
|
|
|
'$(CC) $(LDFLAGS) N.o $(LOADLIBES) $(LDLIBS)'.
|
|
|
|
|
|
This rule does the right thing for a simple program with only one
|
|
|
source file. It will also do the right thing if there are multiple
|
|
|
object files (presumably coming from various other source files),
|
|
|
one of which has a name matching that of the executable file.
|
|
|
Thus,
|
|
|
|
|
|
x: y.o z.o
|
|
|
|
|
|
when 'x.c', 'y.c' and 'z.c' all exist will execute:
|
|
|
|
|
|
cc -c x.c -o x.o
|
|
|
cc -c y.c -o y.o
|
|
|
cc -c z.c -o z.o
|
|
|
cc x.o y.o z.o -o x
|
|
|
rm -f x.o
|
|
|
rm -f y.o
|
|
|
rm -f z.o
|
|
|
|
|
|
In more complicated cases, such as when there is no object file
|
|
|
whose name derives from the executable file name, you must write an
|
|
|
explicit recipe for linking.
|
|
|
|
|
|
Each kind of file automatically made into '.o' object files will be
|
|
|
automatically linked by using the compiler ('$(CC)', '$(FC)' or
|
|
|
'$(PC)'; the C compiler '$(CC)' is used to assemble '.s' files)
|
|
|
without the '-c' option. This could be done by using the '.o'
|
|
|
object files as intermediates, but it is faster to do the compiling
|
|
|
and linking in one step, so that's how it's done.
|
|
|
|
|
|
Yacc for C programs
|
|
|
'N.c' is made automatically from 'N.y' by running Yacc with the
|
|
|
recipe '$(YACC) $(YFLAGS)'.
|
|
|
|
|
|
Lex for C programs
|
|
|
'N.c' is made automatically from 'N.l' by running Lex. The actual
|
|
|
recipe is '$(LEX) $(LFLAGS)'.
|
|
|
|
|
|
Lex for Ratfor programs
|
|
|
'N.r' is made automatically from 'N.l' by running Lex. The actual
|
|
|
recipe is '$(LEX) $(LFLAGS)'.
|
|
|
|
|
|
The convention of using the same suffix '.l' for all Lex files
|
|
|
regardless of whether they produce C code or Ratfor code makes it
|
|
|
impossible for 'make' to determine automatically which of the two
|
|
|
languages you are using in any particular case. If 'make' is
|
|
|
called upon to remake an object file from a '.l' file, it must
|
|
|
guess which compiler to use. It will guess the C compiler, because
|
|
|
that is more common. If you are using Ratfor, make sure 'make'
|
|
|
knows this by mentioning 'N.r' in the makefile. Or, if you are
|
|
|
using Ratfor exclusively, with no C files, remove '.c' from the
|
|
|
list of implicit rule suffixes with:
|
|
|
|
|
|
.SUFFIXES:
|
|
|
.SUFFIXES: .o .r .f .l ...
|
|
|
|
|
|
Making Lint Libraries from C, Yacc, or Lex programs
|
|
|
'N.ln' is made from 'N.c' by running 'lint'. The precise recipe is
|
|
|
'$(LINT) $(LINTFLAGS) $(CPPFLAGS) -i'. The same recipe is used on
|
|
|
the C code produced from 'N.y' or 'N.l'.
|
|
|
|
|
|
TeX and Web
|
|
|
'N.dvi' is made from 'N.tex' with the recipe '$(TEX)'. 'N.tex' is
|
|
|
made from 'N.web' with '$(WEAVE)', or from 'N.w' (and from 'N.ch'
|
|
|
if it exists or can be made) with '$(CWEAVE)'. 'N.p' is made from
|
|
|
'N.web' with '$(TANGLE)' and 'N.c' is made from 'N.w' (and from
|
|
|
'N.ch' if it exists or can be made) with '$(CTANGLE)'.
|
|
|
|
|
|
Texinfo and Info
|
|
|
'N.dvi' is made from 'N.texinfo', 'N.texi', or 'N.txinfo', with the
|
|
|
recipe '$(TEXI2DVI) $(TEXI2DVI_FLAGS)'. 'N.info' is made from
|
|
|
'N.texinfo', 'N.texi', or 'N.txinfo', with the recipe
|
|
|
'$(MAKEINFO) $(MAKEINFO_FLAGS)'.
|
|
|
|
|
|
RCS
|
|
|
Any file 'N' is extracted if necessary from an RCS file named
|
|
|
either 'N,v' or 'RCS/N,v'. The precise recipe used is
|
|
|
'$(CO) $(COFLAGS)'. 'N' will not be extracted from RCS if it
|
|
|
already exists, even if the RCS file is newer. The rules for RCS
|
|
|
are terminal (*note Match-Anything Pattern Rules: Match-Anything
|
|
|
Rules.), so RCS files cannot be generated from another source; they
|
|
|
must actually exist.
|
|
|
|
|
|
SCCS
|
|
|
Any file 'N' is extracted if necessary from an SCCS file named
|
|
|
either 's.N' or 'SCCS/s.N'. The precise recipe used is
|
|
|
'$(GET) $(GFLAGS)'. The rules for SCCS are terminal (*note
|
|
|
Match-Anything Pattern Rules: Match-Anything Rules.), so SCCS files
|
|
|
cannot be generated from another source; they must actually exist.
|
|
|
|
|
|
For the benefit of SCCS, a file 'N' is copied from 'N.sh' and made
|
|
|
executable (by everyone). This is for shell scripts that are
|
|
|
checked into SCCS. Since RCS preserves the execution permission of
|
|
|
a file, you do not need to use this feature with RCS.
|
|
|
|
|
|
We recommend that you avoid using of SCCS. RCS is widely held to be
|
|
|
superior, and is also free. By choosing free software in place of
|
|
|
comparable (or inferior) proprietary software, you support the free
|
|
|
software movement.
|
|
|
|
|
|
Usually, you want to change only the variables listed in the table
|
|
|
above, which are documented in the following section.
|
|
|
|
|
|
However, the recipes in built-in implicit rules actually use
|
|
|
variables such as 'COMPILE.c', 'LINK.p', and 'PREPROCESS.S', whose
|
|
|
values contain the recipes listed above.
|
|
|
|
|
|
'make' follows the convention that the rule to compile a '.X' source
|
|
|
file uses the variable 'COMPILE.X'. Similarly, the rule to produce an
|
|
|
executable from a '.X' file uses 'LINK.X'; and the rule to preprocess a
|
|
|
'.X' file uses 'PREPROCESS.X'.
|
|
|
|
|
|
Every rule that produces an object file uses the variable
|
|
|
'OUTPUT_OPTION'. 'make' defines this variable either to contain '-o
|
|
|
$@', or to be empty, depending on a compile-time option. You need the
|
|
|
'-o' option to ensure that the output goes into the right file when the
|
|
|
source file is in a different directory, as when using 'VPATH' (*note
|
|
|
Directory Search::). However, compilers on some systems do not accept a
|
|
|
'-o' switch for object files. If you use such a system, and use
|
|
|
'VPATH', some compilations will put their output in the wrong place. A
|
|
|
possible workaround for this problem is to give 'OUTPUT_OPTION' the
|
|
|
value '; mv $*.o $@'.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Implicit Variables, Next: Chained Rules, Prev: Catalogue of Rules, Up: Implicit Rules
|
|
|
|
|
|
10.3 Variables Used by Implicit Rules
|
|
|
=====================================
|
|
|
|
|
|
The recipes in built-in implicit rules make liberal use of certain
|
|
|
predefined variables. You can alter the values of these variables in
|
|
|
the makefile, with arguments to 'make', or in the environment to alter
|
|
|
how the implicit rules work without redefining the rules themselves.
|
|
|
You can cancel all variables used by implicit rules with the '-R' or
|
|
|
'--no-builtin-variables' option.
|
|
|
|
|
|
For example, the recipe used to compile a C source file actually says
|
|
|
'$(CC) -c $(CFLAGS) $(CPPFLAGS)'. The default values of the variables
|
|
|
used are 'cc' and nothing, resulting in the command 'cc -c'. By
|
|
|
redefining 'CC' to 'ncc', you could cause 'ncc' to be used for all C
|
|
|
compilations performed by the implicit rule. By redefining 'CFLAGS' to
|
|
|
be '-g', you could pass the '-g' option to each compilation. _All_
|
|
|
implicit rules that do C compilation use '$(CC)' to get the program name
|
|
|
for the compiler and _all_ include '$(CFLAGS)' among the arguments given
|
|
|
to the compiler.
|
|
|
|
|
|
The variables used in implicit rules fall into two classes: those
|
|
|
that are names of programs (like 'CC') and those that contain arguments
|
|
|
for the programs (like 'CFLAGS'). (The "name of a program" may also
|
|
|
contain some command arguments, but it must start with an actual
|
|
|
executable program name.) If a variable value contains more than one
|
|
|
argument, separate them with spaces.
|
|
|
|
|
|
The following tables describe of some of the more commonly-used
|
|
|
predefined variables. This list is not exhaustive, and the default
|
|
|
values shown here may not be what 'make' selects for your environment.
|
|
|
To see the complete list of predefined variables for your instance of
|
|
|
GNU 'make' you can run 'make -p' in a directory with no makefiles.
|
|
|
|
|
|
Here is a table of some of the more common variables used as names of
|
|
|
programs in built-in rules:
|
|
|
|
|
|
'AR'
|
|
|
Archive-maintaining program; default 'ar'.
|
|
|
|
|
|
'AS'
|
|
|
Program for compiling assembly files; default 'as'.
|
|
|
|
|
|
'CC'
|
|
|
Program for compiling C programs; default 'cc'.
|
|
|
|
|
|
'CXX'
|
|
|
Program for compiling C++ programs; default 'g++'.
|
|
|
|
|
|
'CPP'
|
|
|
Program for running the C preprocessor, with results to standard
|
|
|
output; default '$(CC) -E'.
|
|
|
|
|
|
'FC'
|
|
|
Program for compiling or preprocessing Fortran and Ratfor programs;
|
|
|
default 'f77'.
|
|
|
|
|
|
'M2C'
|
|
|
Program to use to compile Modula-2 source code; default 'm2c'.
|
|
|
|
|
|
'PC'
|
|
|
Program for compiling Pascal programs; default 'pc'.
|
|
|
|
|
|
'CO'
|
|
|
Program for extracting a file from RCS; default 'co'.
|
|
|
|
|
|
'GET'
|
|
|
Program for extracting a file from SCCS; default 'get'.
|
|
|
|
|
|
'LEX'
|
|
|
Program to use to turn Lex grammars into source code; default
|
|
|
'lex'.
|
|
|
|
|
|
'YACC'
|
|
|
Program to use to turn Yacc grammars into source code; default
|
|
|
'yacc'.
|
|
|
|
|
|
'LINT'
|
|
|
Program to use to run lint on source code; default 'lint'.
|
|
|
|
|
|
'MAKEINFO'
|
|
|
Program to convert a Texinfo source file into an Info file; default
|
|
|
'makeinfo'.
|
|
|
|
|
|
'TEX'
|
|
|
Program to make TeX DVI files from TeX source; default 'tex'.
|
|
|
|
|
|
'TEXI2DVI'
|
|
|
Program to make TeX DVI files from Texinfo source; default
|
|
|
'texi2dvi'.
|
|
|
|
|
|
'WEAVE'
|
|
|
Program to translate Web into TeX; default 'weave'.
|
|
|
|
|
|
'CWEAVE'
|
|
|
Program to translate C Web into TeX; default 'cweave'.
|
|
|
|
|
|
'TANGLE'
|
|
|
Program to translate Web into Pascal; default 'tangle'.
|
|
|
|
|
|
'CTANGLE'
|
|
|
Program to translate C Web into C; default 'ctangle'.
|
|
|
|
|
|
'RM'
|
|
|
Command to remove a file; default 'rm -f'.
|
|
|
|
|
|
Here is a table of variables whose values are additional arguments
|
|
|
for the programs above. The default values for all of these is the
|
|
|
empty string, unless otherwise noted.
|
|
|
|
|
|
'ARFLAGS'
|
|
|
Flags to give the archive-maintaining program; default 'rv'.
|
|
|
|
|
|
'ASFLAGS'
|
|
|
Extra flags to give to the assembler (when explicitly invoked on a
|
|
|
'.s' or '.S' file).
|
|
|
|
|
|
'CFLAGS'
|
|
|
Extra flags to give to the C compiler.
|
|
|
|
|
|
'CXXFLAGS'
|
|
|
Extra flags to give to the C++ compiler.
|
|
|
|
|
|
'COFLAGS'
|
|
|
Extra flags to give to the RCS 'co' program.
|
|
|
|
|
|
'CPPFLAGS'
|
|
|
Extra flags to give to the C preprocessor and programs that use it
|
|
|
(the C and Fortran compilers).
|
|
|
|
|
|
'FFLAGS'
|
|
|
Extra flags to give to the Fortran compiler.
|
|
|
|
|
|
'GFLAGS'
|
|
|
Extra flags to give to the SCCS 'get' program.
|
|
|
|
|
|
'LDFLAGS'
|
|
|
Extra flags to give to compilers when they are supposed to invoke
|
|
|
the linker, 'ld', such as '-L'. Libraries ('-lfoo') should be
|
|
|
added to the 'LDLIBS' variable instead.
|
|
|
|
|
|
'LDLIBS'
|
|
|
Library flags or names given to compilers when they are supposed to
|
|
|
invoke the linker, 'ld'. 'LOADLIBES' is a deprecated (but still
|
|
|
supported) alternative to 'LDLIBS'. Non-library linker flags, such
|
|
|
as '-L', should go in the 'LDFLAGS' variable.
|
|
|
|
|
|
'LFLAGS'
|
|
|
Extra flags to give to Lex.
|
|
|
|
|
|
'YFLAGS'
|
|
|
Extra flags to give to Yacc.
|
|
|
|
|
|
'PFLAGS'
|
|
|
Extra flags to give to the Pascal compiler.
|
|
|
|
|
|
'RFLAGS'
|
|
|
Extra flags to give to the Fortran compiler for Ratfor programs.
|
|
|
|
|
|
'LINTFLAGS'
|
|
|
Extra flags to give to lint.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Chained Rules, Next: Pattern Rules, Prev: Implicit Variables, Up: Implicit Rules
|
|
|
|
|
|
10.4 Chains of Implicit Rules
|
|
|
=============================
|
|
|
|
|
|
Sometimes a file can be made by a sequence of implicit rules. For
|
|
|
example, a file 'N.o' could be made from 'N.y' by running first Yacc and
|
|
|
then 'cc'. Such a sequence is called a "chain".
|
|
|
|
|
|
If the file 'N.c' exists, or is mentioned in the makefile, no special
|
|
|
searching is required: 'make' finds that the object file can be made by
|
|
|
C compilation from 'N.c'; later on, when considering how to make 'N.c',
|
|
|
the rule for running Yacc is used. Ultimately both 'N.c' and 'N.o' are
|
|
|
updated.
|
|
|
|
|
|
However, even if 'N.c' does not exist and is not mentioned, 'make'
|
|
|
knows how to envision it as the missing link between 'N.o' and 'N.y'!
|
|
|
In this case, 'N.c' is called an "intermediate file". Once 'make' has
|
|
|
decided to use the intermediate file, it is entered in the data base as
|
|
|
if it had been mentioned in the makefile, along with the implicit rule
|
|
|
that says how to create it.
|
|
|
|
|
|
Intermediate files are remade using their rules just like all other
|
|
|
files. But intermediate files are treated differently in two ways.
|
|
|
|
|
|
The first difference is what happens if the intermediate file does
|
|
|
not exist. If an ordinary file B does not exist, and 'make' considers a
|
|
|
target that depends on B, it invariably creates B and then updates the
|
|
|
target from B. But if B is an intermediate file, then 'make' can leave
|
|
|
well enough alone. It won't bother updating B, or the ultimate target,
|
|
|
unless some prerequisite of B is newer than that target or there is some
|
|
|
other reason to update that target.
|
|
|
|
|
|
The second difference is that if 'make' _does_ create B in order to
|
|
|
update something else, it deletes B later on after it is no longer
|
|
|
needed. Therefore, an intermediate file which did not exist before
|
|
|
'make' also does not exist after 'make'. 'make' reports the deletion to
|
|
|
you by printing a 'rm -f' command showing which file it is deleting.
|
|
|
|
|
|
Ordinarily, a file cannot be intermediate if it is mentioned in the
|
|
|
makefile as a target or prerequisite. However, you can explicitly mark
|
|
|
a file as intermediate by listing it as a prerequisite of the special
|
|
|
target '.INTERMEDIATE'. This takes effect even if the file is mentioned
|
|
|
explicitly in some other way.
|
|
|
|
|
|
You can prevent automatic deletion of an intermediate file by marking
|
|
|
it as a "secondary" file. To do this, list it as a prerequisite of the
|
|
|
special target '.SECONDARY'. When a file is secondary, 'make' will not
|
|
|
create the file merely because it does not already exist, but 'make'
|
|
|
does not automatically delete the file. Marking a file as secondary
|
|
|
also marks it as intermediate.
|
|
|
|
|
|
You can list the target pattern of an implicit rule (such as '%.o')
|
|
|
as a prerequisite of the special target '.PRECIOUS' to preserve
|
|
|
intermediate files made by implicit rules whose target patterns match
|
|
|
that file's name; see *note Interrupts::.
|
|
|
|
|
|
A chain can involve more than two implicit rules. For example, it is
|
|
|
possible to make a file 'foo' from 'RCS/foo.y,v' by running RCS, Yacc
|
|
|
and 'cc'. Then both 'foo.y' and 'foo.c' are intermediate files that are
|
|
|
deleted at the end.
|
|
|
|
|
|
No single implicit rule can appear more than once in a chain. This
|
|
|
means that 'make' will not even consider such a ridiculous thing as
|
|
|
making 'foo' from 'foo.o.o' by running the linker twice. This
|
|
|
constraint has the added benefit of preventing any infinite loop in the
|
|
|
search for an implicit rule chain.
|
|
|
|
|
|
There are some special implicit rules to optimize certain cases that
|
|
|
would otherwise be handled by rule chains. For example, making 'foo'
|
|
|
from 'foo.c' could be handled by compiling and linking with separate
|
|
|
chained rules, using 'foo.o' as an intermediate file. But what actually
|
|
|
happens is that a special rule for this case does the compilation and
|
|
|
linking with a single 'cc' command. The optimized rule is used in
|
|
|
preference to the step-by-step chain because it comes earlier in the
|
|
|
ordering of rules.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Pattern Rules, Next: Last Resort, Prev: Chained Rules, Up: Implicit Rules
|
|
|
|
|
|
10.5 Defining and Redefining Pattern Rules
|
|
|
==========================================
|
|
|
|
|
|
You define an implicit rule by writing a "pattern rule". A pattern rule
|
|
|
looks like an ordinary rule, except that its target contains the
|
|
|
character '%' (exactly one of them). The target is considered a pattern
|
|
|
for matching file names; the '%' can match any nonempty substring, while
|
|
|
other characters match only themselves. The prerequisites likewise use
|
|
|
'%' to show how their names relate to the target name.
|
|
|
|
|
|
Thus, a pattern rule '%.o : %.c' says how to make any file 'STEM.o'
|
|
|
from another file 'STEM.c'.
|
|
|
|
|
|
Note that expansion using '%' in pattern rules occurs *after* any
|
|
|
variable or function expansions, which take place when the makefile is
|
|
|
read. *Note How to Use Variables: Using Variables, and *note Functions
|
|
|
for Transforming Text: Functions.
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* Pattern Intro:: An introduction to pattern rules.
|
|
|
* Pattern Examples:: Examples of pattern rules.
|
|
|
* Automatic Variables:: How to use automatic variables in the
|
|
|
recipe of implicit rules.
|
|
|
* Pattern Match:: How patterns match.
|
|
|
* Match-Anything Rules:: Precautions you should take prior to
|
|
|
defining rules that can match any
|
|
|
target file whatever.
|
|
|
* Canceling Rules:: How to override or cancel built-in rules.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Pattern Intro, Next: Pattern Examples, Prev: Pattern Rules, Up: Pattern Rules
|
|
|
|
|
|
10.5.1 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 all of its prerequisites (after pattern substitution) must name
|
|
|
files that exist or can be made. These files become prerequisites of
|
|
|
the target.
|
|
|
|
|
|
Thus, a rule of the form
|
|
|
|
|
|
%.o : %.c ; RECIPE...
|
|
|
|
|
|
specifies how to make a file 'N.o', with another file 'N.c' as its
|
|
|
prerequisite, provided that 'N.c' exists or can be made.
|
|
|
|
|
|
There may also be prerequisites that do not use '%'; such a
|
|
|
prerequisite attaches to every file made by this pattern rule. These
|
|
|
unvarying prerequisites are useful occasionally.
|
|
|
|
|
|
A pattern rule need not have any prerequisites that contain '%', or
|
|
|
in fact any prerequisites at all. Such a rule is effectively a general
|
|
|
wildcard. It provides a way to make any file that matches the target
|
|
|
pattern. *Note Last Resort::.
|
|
|
|
|
|
More than one pattern rule may match a target. In this case 'make'
|
|
|
will choose the "best fit" rule. *Note How Patterns Match: Pattern
|
|
|
Match.
|
|
|
|
|
|
Pattern rules may have more than one target. Unlike normal rules,
|
|
|
this does not act as many different rules with the same prerequisites
|
|
|
and recipe. If a pattern rule has multiple targets, 'make' knows that
|
|
|
the rule's recipe is responsible for making all of the targets. The
|
|
|
recipe is executed only once to make all the targets. When searching
|
|
|
for a pattern rule to match a target, the target patterns of a rule
|
|
|
other than the one that matches the target in need of a rule are
|
|
|
incidental: 'make' worries only about giving a recipe and prerequisites
|
|
|
to the file presently in question. However, when this file's recipe is
|
|
|
run, the other targets are marked as having been updated themselves.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Pattern Examples, Next: Automatic Variables, Prev: Pattern Intro, Up: Pattern Rules
|
|
|
|
|
|
10.5.2 Pattern Rule Examples
|
|
|
----------------------------
|
|
|
|
|
|
Here are some examples of pattern rules actually predefined in 'make'.
|
|
|
First, the rule that compiles '.c' files into '.o' files:
|
|
|
|
|
|
%.o : %.c
|
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) $< -o $@
|
|
|
|
|
|
defines a rule that can make any file 'X.o' from 'X.c'. The recipe uses
|
|
|
the automatic variables '$@' and '$<' to substitute the names of the
|
|
|
target file and the source file in each case where the rule applies
|
|
|
(*note Automatic Variables::).
|
|
|
|
|
|
Here is a second built-in rule:
|
|
|
|
|
|
% :: RCS/%,v
|
|
|
$(CO) $(COFLAGS) $<
|
|
|
|
|
|
defines a rule that can make any file 'X' whatsoever from a
|
|
|
corresponding file 'X,v' in the sub-directory 'RCS'. Since the target
|
|
|
is '%', this rule will apply to any file whatever, provided the
|
|
|
appropriate prerequisite file exists. The double colon makes the rule
|
|
|
"terminal", which means that its prerequisite may not be an intermediate
|
|
|
file (*note Match-Anything Pattern Rules: Match-Anything Rules.).
|
|
|
|
|
|
This pattern rule has two targets:
|
|
|
|
|
|
%.tab.c %.tab.h: %.y
|
|
|
bison -d $<
|
|
|
|
|
|
This tells 'make' that the recipe 'bison -d X.y' will make both
|
|
|
'X.tab.c' and 'X.tab.h'. If the file 'foo' depends on the files
|
|
|
'parse.tab.o' and 'scan.o' and the file 'scan.o' depends on the file
|
|
|
'parse.tab.h', when 'parse.y' is changed, the recipe 'bison -d parse.y'
|
|
|
will be executed only once, and the prerequisites of both 'parse.tab.o'
|
|
|
and 'scan.o' will be satisfied. (Presumably the file 'parse.tab.o' will
|
|
|
be recompiled from 'parse.tab.c' and the file 'scan.o' from 'scan.c',
|
|
|
while 'foo' is linked from 'parse.tab.o', 'scan.o', and its other
|
|
|
prerequisites, and it will execute happily ever after.)
|
|
|
|
|
|
|
|
|
File: make.info, Node: Automatic Variables, Next: Pattern Match, Prev: Pattern Examples, Up: Pattern Rules
|
|
|
|
|
|
10.5.3 Automatic Variables
|
|
|
--------------------------
|
|
|
|
|
|
Suppose you are writing a pattern rule to compile a '.c' file into a
|
|
|
'.o' file: how do you write the 'cc' command so that it operates on the
|
|
|
right source file name? You cannot write the name in the recipe,
|
|
|
because the name is different each time the implicit rule is applied.
|
|
|
|
|
|
What you do is use a special feature of 'make', the "automatic
|
|
|
variables". These variables have values computed afresh for each rule
|
|
|
that is executed, based on the target and prerequisites of the rule. In
|
|
|
this example, you would use '$@' for the object file name and '$<' for
|
|
|
the source file name.
|
|
|
|
|
|
It's very important that you recognize the limited scope in which
|
|
|
automatic variable values are available: they only have values within
|
|
|
the recipe. In particular, you cannot use them anywhere within the
|
|
|
target list of a rule; they have no value there and will expand to the
|
|
|
empty string. Also, they cannot be accessed directly within the
|
|
|
prerequisite list of a rule. A common mistake is attempting to use '$@'
|
|
|
within the prerequisites list; this will not work. However, there is a
|
|
|
special feature of GNU 'make', secondary expansion (*note Secondary
|
|
|
Expansion::), which will allow automatic variable values to be used in
|
|
|
prerequisite lists.
|
|
|
|
|
|
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 recipe 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 recipe
|
|
|
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 named member is used (*note Archives::).
|
|
|
|
|
|
'$^'
|
|
|
The names of all the prerequisites, with spaces between them. For
|
|
|
prerequisites which are archive members, only the named member 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 list does *not* contain any of the order-only
|
|
|
prerequisites; for those see the '$|' variable, below.
|
|
|
|
|
|
'$+'
|
|
|
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 names of all the order-only prerequisites, with spaces between
|
|
|
them.
|
|
|
|
|
|
'$*'
|
|
|
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.
|
|
|
|
|
|
'$?' is useful even in explicit rules when you wish to operate on
|
|
|
only the prerequisites that have changed. For example, suppose that an
|
|
|
archive named 'lib' is supposed to contain copies of several object
|
|
|
files. This rule copies just the changed object files into the archive:
|
|
|
|
|
|
lib: foo.o bar.o lose.o win.o
|
|
|
ar r lib $?
|
|
|
|
|
|
Of the variables listed above, four have values that are single file
|
|
|
names, and three have values that are lists of file names. These seven
|
|
|
have variants that get just the file's directory name or just the file
|
|
|
name within the directory. The variant variables' names are formed by
|
|
|
appending 'D' or 'F', respectively. These variants are semi-obsolete in
|
|
|
GNU 'make' since the functions 'dir' and 'notdir' can be used to get a
|
|
|
similar effect (*note Functions for File Names: File Name Functions.).
|
|
|
Note, however, that the 'D' variants all omit the trailing slash which
|
|
|
always appears in the output of the 'dir' function. Here is a table of
|
|
|
the variants:
|
|
|
|
|
|
'$(@D)'
|
|
|
The directory part of the file name of the target, with the
|
|
|
trailing slash removed. If the value of '$@' is 'dir/foo.o' then
|
|
|
'$(@D)' is 'dir'. This value is '.' if '$@' does not contain a
|
|
|
slash.
|
|
|
|
|
|
'$(@F)'
|
|
|
The file-within-directory part of the file name of the target. If
|
|
|
the value of '$@' is 'dir/foo.o' then '$(@F)' is 'foo.o'. '$(@F)'
|
|
|
is equivalent to '$(notdir $@)'.
|
|
|
|
|
|
'$(*D)'
|
|
|
'$(*F)'
|
|
|
The directory part and the file-within-directory part of the stem;
|
|
|
'dir' and 'foo' in this example.
|
|
|
|
|
|
'$(%D)'
|
|
|
'$(%F)'
|
|
|
The directory part and the file-within-directory part of the target
|
|
|
archive member name. This makes sense only for archive member
|
|
|
targets of the form 'ARCHIVE(MEMBER)' and is useful only when
|
|
|
MEMBER may contain a directory name. (*Note Archive Members as
|
|
|
Targets: Archive Members.)
|
|
|
|
|
|
'$(<D)'
|
|
|
'$(<F)'
|
|
|
The directory part and the file-within-directory part of the first
|
|
|
prerequisite.
|
|
|
|
|
|
'$(^D)'
|
|
|
'$(^F)'
|
|
|
Lists of the directory parts and the file-within-directory parts of
|
|
|
all prerequisites.
|
|
|
|
|
|
'$(+D)'
|
|
|
'$(+F)'
|
|
|
Lists of the directory parts and the file-within-directory parts of
|
|
|
all prerequisites, including multiple instances of duplicated
|
|
|
prerequisites.
|
|
|
|
|
|
'$(?D)'
|
|
|
'$(?F)'
|
|
|
Lists of the directory parts and the file-within-directory parts of
|
|
|
all prerequisites that are newer than the target.
|
|
|
|
|
|
Note that we use a special stylistic convention when we talk about
|
|
|
these automatic variables; we write "the value of '$<'", rather than "the variable '<'"
|
|
|
as we would write for ordinary variables such as 'objects' and 'CFLAGS'.
|
|
|
We think this convention looks more natural in this special case.
|
|
|
Please do not assume it has a deep significance; '$<' refers to the
|
|
|
variable named '<' just as '$(CFLAGS)' refers to the variable named
|
|
|
'CFLAGS'. You could just as well use '$(<)' in place of '$<'.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Pattern Match, Next: Match-Anything Rules, Prev: Automatic Variables, Up: Pattern Rules
|
|
|
|
|
|
10.5.4 How Patterns Match
|
|
|
-------------------------
|
|
|
|
|
|
A target pattern is composed of a '%' between a prefix and a suffix,
|
|
|
either or both of which may be empty. The pattern matches a file name
|
|
|
only if the file name starts with the prefix and ends with the suffix,
|
|
|
without overlap. The text between the prefix and the suffix is called
|
|
|
the "stem". Thus, when the pattern '%.o' matches the file name
|
|
|
'test.o', the stem is 'test'. The pattern rule prerequisites are turned
|
|
|
into actual file names by substituting the stem for the character '%'.
|
|
|
Thus, if in the same example one of the prerequisites is written as
|
|
|
'%.c', it expands to 'test.c'.
|
|
|
|
|
|
When the target pattern does not contain a slash (and it usually does
|
|
|
not), directory names in the file names are removed from the file name
|
|
|
before it is compared with the target prefix and suffix. After the
|
|
|
comparison of the file name to the target pattern, the directory names,
|
|
|
along with the slash that ends them, are added on to the prerequisite
|
|
|
file names generated from the pattern rule's prerequisite patterns and
|
|
|
the file name. The directories are ignored only for the purpose of
|
|
|
finding an implicit rule to use, not in the application of that rule.
|
|
|
Thus, 'e%t' matches the file name 'src/eat', with 'src/a' as the stem.
|
|
|
When prerequisites are turned into file names, the directories from the
|
|
|
stem are added at the front, while the rest of the stem is substituted
|
|
|
for the '%'. The stem 'src/a' with a prerequisite pattern 'c%r' gives
|
|
|
the file name 'src/car'.
|
|
|
|
|
|
A pattern rule can be used to build a given file only if there is a
|
|
|
target pattern that matches the file name, _and_ all prerequisites in
|
|
|
that rule either exist or can be built. The rules you write take
|
|
|
precedence over those that are built in. Note however, that a rule
|
|
|
whose prerequisites actually exist or are mentioned always takes
|
|
|
priority over a rule with prerequisites that must be made by chaining
|
|
|
other implicit rules.
|
|
|
|
|
|
It is possible that more than one pattern rule will meet these
|
|
|
criteria. In that case, 'make' will choose the rule with the shortest
|
|
|
stem (that is, the pattern that matches most specifically). If more
|
|
|
than one pattern rule has the shortest stem, 'make' will choose the
|
|
|
first one found in the makefile.
|
|
|
|
|
|
This algorithm results in more specific rules being preferred over
|
|
|
more generic ones; for example:
|
|
|
|
|
|
%.o: %.c
|
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) $< -o $@
|
|
|
|
|
|
%.o : %.f
|
|
|
$(COMPILE.F) $(OUTPUT_OPTION) $<
|
|
|
|
|
|
lib/%.o: lib/%.c
|
|
|
$(CC) -fPIC -c $(CFLAGS) $(CPPFLAGS) $< -o $@
|
|
|
|
|
|
Given these rules and asked to build 'bar.o' where both 'bar.c' and
|
|
|
'bar.f' exist, 'make' will choose the first rule and compile 'bar.c'
|
|
|
into 'bar.o'. In the same situation where 'bar.c' does not exist, then
|
|
|
'make' will choose the second rule and compile 'bar.f' into 'bar.o'.
|
|
|
|
|
|
If 'make' is asked to build 'lib/bar.o' and both 'lib/bar.c' and
|
|
|
'lib/bar.f' exist, then the third rule will be chosen since the stem for
|
|
|
this rule ('bar') is shorter than the stem for the first rule
|
|
|
('lib/bar'). If 'lib/bar.c' does not exist then the third rule is not
|
|
|
eligible and the second rule will be used, even though the stem is
|
|
|
longer.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Match-Anything Rules, Next: Canceling Rules, Prev: Pattern Match, Up: Pattern Rules
|
|
|
|
|
|
10.5.5 Match-Anything Pattern Rules
|
|
|
-----------------------------------
|
|
|
|
|
|
When a pattern rule's target is just '%', it matches any file name
|
|
|
whatever. We call these rules "match-anything" rules. They are very
|
|
|
useful, but it can take a lot of time for 'make' to think about them,
|
|
|
because it must consider every such rule for each file name listed
|
|
|
either as a target or as a prerequisite.
|
|
|
|
|
|
Suppose the makefile mentions 'foo.c'. For this target, 'make' would
|
|
|
have to consider making it by linking an object file 'foo.c.o', or by C
|
|
|
compilation-and-linking in one step from 'foo.c.c', or by Pascal
|
|
|
compilation-and-linking from 'foo.c.p', and many other possibilities.
|
|
|
|
|
|
We know these possibilities are ridiculous since 'foo.c' is a C
|
|
|
source file, not an executable. If 'make' did consider these
|
|
|
possibilities, it would ultimately reject them, because files such as
|
|
|
'foo.c.o' and 'foo.c.p' would not exist. But these possibilities are so
|
|
|
numerous that 'make' would run very slowly if it had to consider them.
|
|
|
|
|
|
To gain speed, we have put various constraints on the way 'make'
|
|
|
considers match-anything rules. There are two different constraints
|
|
|
that can be applied, and each time you define a match-anything rule you
|
|
|
must choose one or the other for that rule.
|
|
|
|
|
|
One choice is to mark the match-anything rule as "terminal" by
|
|
|
defining it with a double colon. When a rule is terminal, it does not
|
|
|
apply unless its prerequisites actually exist. Prerequisites that could
|
|
|
be made with other implicit rules are not good enough. In other words,
|
|
|
no further chaining is allowed beyond a terminal rule.
|
|
|
|
|
|
For example, the built-in implicit rules for extracting sources from
|
|
|
RCS and SCCS files are terminal; as a result, if the file 'foo.c,v' does
|
|
|
not exist, 'make' will not even consider trying to make it as an
|
|
|
intermediate file from 'foo.c,v.o' or from 'RCS/SCCS/s.foo.c,v'. RCS
|
|
|
and SCCS files are generally ultimate source files, which should not be
|
|
|
remade from any other files; therefore, 'make' can save time by not
|
|
|
looking for ways to remake them.
|
|
|
|
|
|
If you do not mark the match-anything rule as terminal, then it is
|
|
|
non-terminal. A non-terminal match-anything rule cannot apply to a file
|
|
|
name that indicates a specific type of data. A file name indicates a
|
|
|
specific type of data if some non-match-anything implicit rule target
|
|
|
matches it.
|
|
|
|
|
|
For example, the file name 'foo.c' matches the target for the pattern
|
|
|
rule '%.c : %.y' (the rule to run Yacc). Regardless of whether this
|
|
|
rule is actually applicable (which happens only if there is a file
|
|
|
'foo.y'), the fact that its target matches is enough to prevent
|
|
|
consideration of any non-terminal match-anything rules for the file
|
|
|
'foo.c'. Thus, 'make' will not even consider trying to make 'foo.c' as
|
|
|
an executable file from 'foo.c.o', 'foo.c.c', 'foo.c.p', etc.
|
|
|
|
|
|
The motivation for this constraint is that non-terminal
|
|
|
match-anything rules are used for making files containing specific types
|
|
|
of data (such as executable files) and a file name with a recognized
|
|
|
suffix indicates some other specific type of data (such as a C source
|
|
|
file).
|
|
|
|
|
|
Special built-in dummy pattern rules are provided solely to recognize
|
|
|
certain file names so that non-terminal match-anything rules will not be
|
|
|
considered. These dummy rules have no prerequisites and no recipes, and
|
|
|
they are ignored for all other purposes. For example, the built-in
|
|
|
implicit rule
|
|
|
|
|
|
%.p :
|
|
|
|
|
|
exists to make sure that Pascal source files such as 'foo.p' match a
|
|
|
specific target pattern and thereby prevent time from being wasted
|
|
|
looking for 'foo.p.o' or 'foo.p.c'.
|
|
|
|
|
|
Dummy pattern rules such as the one for '%.p' are made for every
|
|
|
suffix listed as valid for use in suffix rules (*note Old-Fashioned
|
|
|
Suffix Rules: Suffix Rules.).
|
|
|
|
|
|
|
|
|
File: make.info, Node: Canceling Rules, Prev: Match-Anything Rules, Up: Pattern Rules
|
|
|
|
|
|
10.5.6 Canceling Implicit Rules
|
|
|
-------------------------------
|
|
|
|
|
|
You can override a built-in implicit rule (or one you have defined
|
|
|
yourself) by defining a new pattern rule with the same target and
|
|
|
prerequisites, but a different recipe. When the new rule is defined,
|
|
|
the built-in one is replaced. The new rule's position in the sequence
|
|
|
of implicit rules is determined by where you write the new rule.
|
|
|
|
|
|
You can cancel a built-in implicit rule by defining a pattern rule
|
|
|
with the same target and prerequisites, but no recipe. For example, the
|
|
|
following would cancel the rule that runs the assembler:
|
|
|
|
|
|
%.o : %.s
|
|
|
|
|
|
|
|
|
File: make.info, Node: Last Resort, Next: Suffix Rules, Prev: Pattern Rules, Up: Implicit Rules
|
|
|
|
|
|
10.6 Defining Last-Resort Default Rules
|
|
|
=======================================
|
|
|
|
|
|
You can define a last-resort implicit rule by writing a terminal
|
|
|
match-anything pattern rule with no prerequisites (*note Match-Anything
|
|
|
Rules::). This is just like any other pattern rule; the only thing
|
|
|
special about it is that it will match any target. So such a rule's
|
|
|
recipe is used for all targets and prerequisites that have no recipe of
|
|
|
their own and for which no other implicit rule applies.
|
|
|
|
|
|
For example, when testing a makefile, you might not care if the
|
|
|
source files contain real data, only that they exist. Then you might do
|
|
|
this:
|
|
|
|
|
|
%::
|
|
|
touch $@
|
|
|
|
|
|
to cause all the source files needed (as prerequisites) to be created
|
|
|
automatically.
|
|
|
|
|
|
You can instead define a recipe to be used for targets for which
|
|
|
there are no rules at all, even ones which don't specify recipes. You
|
|
|
do this by writing a rule for the target '.DEFAULT'. Such a rule's
|
|
|
recipe is used for all prerequisites which do not appear as targets in
|
|
|
any explicit rule, and for which no implicit rule applies. Naturally,
|
|
|
there is no '.DEFAULT' rule unless you write one.
|
|
|
|
|
|
If you use '.DEFAULT' with no recipe or prerequisites:
|
|
|
|
|
|
.DEFAULT:
|
|
|
|
|
|
the recipe previously stored for '.DEFAULT' is cleared. Then 'make'
|
|
|
acts as if you had never defined '.DEFAULT' at all.
|
|
|
|
|
|
If you do not want a target to get the recipe from a match-anything
|
|
|
pattern rule or '.DEFAULT', but you also do not want any recipe to be
|
|
|
run for the target, you can give it an empty recipe (*note Defining
|
|
|
Empty Recipes: Empty Recipes.).
|
|
|
|
|
|
You can use a last-resort rule to override part of another makefile.
|
|
|
*Note Overriding Part of Another Makefile: Overriding Makefiles.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Suffix Rules, Next: Implicit Rule Search, Prev: Last Resort, Up: Implicit Rules
|
|
|
|
|
|
10.7 Old-Fashioned Suffix Rules
|
|
|
===============================
|
|
|
|
|
|
"Suffix rules" are the old-fashioned way of defining implicit rules for
|
|
|
'make'. Suffix rules are obsolete because pattern rules are more
|
|
|
general and clearer. They are supported in GNU 'make' for compatibility
|
|
|
with old makefiles. They come in two kinds: "double-suffix" and
|
|
|
"single-suffix".
|
|
|
|
|
|
A double-suffix rule is defined by a pair of suffixes: the target
|
|
|
suffix and the source suffix. It matches any file whose name ends with
|
|
|
the target suffix. The corresponding implicit prerequisite is made by
|
|
|
replacing the target suffix with the source suffix in the file name. A
|
|
|
two-suffix rule whose target and source suffixes are '.o' and '.c' is
|
|
|
equivalent to the pattern rule '%.o : %.c'.
|
|
|
|
|
|
A single-suffix rule is defined by a single suffix, which is the
|
|
|
source suffix. It matches any file name, and the corresponding implicit
|
|
|
prerequisite name is made by appending the source suffix. A
|
|
|
single-suffix rule whose source suffix is '.c' is equivalent to the
|
|
|
pattern rule '% : %.c'.
|
|
|
|
|
|
Suffix rule definitions are recognized by comparing each rule's
|
|
|
target against a defined list of known suffixes. When 'make' sees a
|
|
|
rule whose target is a known suffix, this rule is considered a
|
|
|
single-suffix rule. When 'make' sees a rule whose target is two known
|
|
|
suffixes concatenated, this rule is taken as a double-suffix rule.
|
|
|
|
|
|
For example, '.c' and '.o' are both on the default list of known
|
|
|
suffixes. Therefore, if you define a rule whose target is '.c.o',
|
|
|
'make' takes it to be a double-suffix rule with source suffix '.c' and
|
|
|
target suffix '.o'. Here is the old-fashioned way to define the rule
|
|
|
for compiling a C source file:
|
|
|
|
|
|
.c.o:
|
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
|
|
|
|
|
|
Suffix rules cannot have any prerequisites of their own. If they
|
|
|
have any, they are treated as normal files with funny names, not as
|
|
|
suffix rules. Thus, the rule:
|
|
|
|
|
|
.c.o: foo.h
|
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
|
|
|
|
|
|
tells how to make the file '.c.o' from the prerequisite file 'foo.h',
|
|
|
and is not at all like the pattern rule:
|
|
|
|
|
|
%.o: %.c foo.h
|
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
|
|
|
|
|
|
which tells how to make '.o' files from '.c' files, and makes all '.o'
|
|
|
files using this pattern rule also depend on 'foo.h'.
|
|
|
|
|
|
Suffix rules with no recipe are also meaningless. They do not remove
|
|
|
previous rules as do pattern rules with no recipe (*note Canceling
|
|
|
Implicit Rules: Canceling Rules.). They simply enter the suffix or pair
|
|
|
of suffixes concatenated as a target in the data base.
|
|
|
|
|
|
The known suffixes are simply the names of the prerequisites of the
|
|
|
special target '.SUFFIXES'. You can add your own suffixes by writing a
|
|
|
rule for '.SUFFIXES' that adds more prerequisites, as in:
|
|
|
|
|
|
.SUFFIXES: .hack .win
|
|
|
|
|
|
which adds '.hack' and '.win' to the end of the list of suffixes.
|
|
|
|
|
|
If you wish to eliminate the default known suffixes instead of just
|
|
|
adding to them, write a rule for '.SUFFIXES' with no prerequisites. By
|
|
|
special dispensation, this eliminates all existing prerequisites of
|
|
|
'.SUFFIXES'. You can then write another rule to add the suffixes you
|
|
|
want. For example,
|
|
|
|
|
|
.SUFFIXES: # Delete the default suffixes
|
|
|
.SUFFIXES: .c .o .h # Define our suffix list
|
|
|
|
|
|
The '-r' or '--no-builtin-rules' flag causes the default list of
|
|
|
suffixes to be empty.
|
|
|
|
|
|
The variable 'SUFFIXES' is defined to the default list of suffixes
|
|
|
before 'make' reads any makefiles. You can change the list of suffixes
|
|
|
with a rule for the special target '.SUFFIXES', but that does not alter
|
|
|
this variable.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Implicit Rule Search, Prev: Suffix Rules, Up: Implicit Rules
|
|
|
|
|
|
10.8 Implicit Rule Search Algorithm
|
|
|
===================================
|
|
|
|
|
|
Here is the procedure 'make' uses for searching for an implicit rule for
|
|
|
a target T. This procedure is followed for each double-colon rule with
|
|
|
no recipe, for each target of ordinary rules none of which have a
|
|
|
recipe, and for each prerequisite that is not the target of any rule.
|
|
|
It is also followed recursively for prerequisites that come from
|
|
|
implicit rules, in the search for a chain of rules.
|
|
|
|
|
|
Suffix rules are not mentioned in this algorithm because suffix rules
|
|
|
are converted to equivalent pattern rules once the makefiles have been
|
|
|
read in.
|
|
|
|
|
|
For an archive member target of the form 'ARCHIVE(MEMBER)', the
|
|
|
following algorithm is run twice, first using the entire target name T,
|
|
|
and second using '(MEMBER)' as the target T if the first run found no
|
|
|
rule.
|
|
|
|
|
|
1. Split T into a directory part, called D, and the rest, called N.
|
|
|
For example, if T is 'src/foo.o', then D is 'src/' and N is
|
|
|
'foo.o'.
|
|
|
|
|
|
2. Make a list of all the pattern rules one of whose targets matches T
|
|
|
or N. If the target pattern contains a slash, it is matched
|
|
|
against T; otherwise, against N.
|
|
|
|
|
|
3. If any rule in that list is _not_ a match-anything rule, then
|
|
|
remove all non-terminal match-anything rules from the list.
|
|
|
|
|
|
4. Remove from the list all rules with no recipe.
|
|
|
|
|
|
5. For each pattern rule in the list:
|
|
|
|
|
|
a. Find the stem S, which is the nonempty part of T or N matched
|
|
|
by the '%' in the target pattern.
|
|
|
|
|
|
b. Compute the prerequisite names by substituting S for '%'; if
|
|
|
the target pattern does not contain a slash, append D to the
|
|
|
front of each prerequisite name.
|
|
|
|
|
|
c. Test whether all the prerequisites exist or ought to exist.
|
|
|
(If a file name is mentioned in the makefile as a target or as
|
|
|
an explicit prerequisite, then we say it ought to exist.)
|
|
|
|
|
|
If all prerequisites exist or ought to exist, or there are no
|
|
|
prerequisites, then this rule applies.
|
|
|
|
|
|
6. If no pattern rule has been found so far, try harder. For each
|
|
|
pattern rule in the list:
|
|
|
|
|
|
a. If the rule is terminal, ignore it and go on to the next rule.
|
|
|
|
|
|
b. Compute the prerequisite names as before.
|
|
|
|
|
|
c. Test whether all the prerequisites exist or ought to exist.
|
|
|
|
|
|
d. For each prerequisite that does not exist, follow this
|
|
|
algorithm recursively to see if the prerequisite can be made
|
|
|
by an implicit rule.
|
|
|
|
|
|
e. If all prerequisites exist, ought to exist, or can be made by
|
|
|
implicit rules, then this rule applies.
|
|
|
|
|
|
7. If no implicit rule applies, the rule for '.DEFAULT', if any,
|
|
|
applies. In that case, give T the same recipe that '.DEFAULT' has.
|
|
|
Otherwise, there is no recipe for T.
|
|
|
|
|
|
Once a rule that applies has been found, for each target pattern of
|
|
|
the rule other than the one that matched T or N, the '%' in the pattern
|
|
|
is replaced with S and the resultant file name is stored until the
|
|
|
recipe to remake the target file T is executed. After the recipe is
|
|
|
executed, each of these stored file names are entered into the data base
|
|
|
and marked as having been updated and having the same update status as
|
|
|
the file T.
|
|
|
|
|
|
When the recipe of a pattern rule is executed for T, the automatic
|
|
|
variables are set corresponding to the target and prerequisites. *Note
|
|
|
Automatic Variables::.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Archives, Next: Extending make, Prev: Implicit Rules, Up: Top
|
|
|
|
|
|
11 Using 'make' to Update Archive Files
|
|
|
***************************************
|
|
|
|
|
|
"Archive files" are files containing named sub-files called "members";
|
|
|
they are maintained with the program 'ar' and their main use is as
|
|
|
subroutine libraries for linking.
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* Archive Members:: Archive members as targets.
|
|
|
* Archive Update:: The implicit rule for archive member targets.
|
|
|
* Archive Pitfalls:: Dangers to watch out for when using archives.
|
|
|
* Archive Suffix Rules:: You can write a special kind of suffix rule
|
|
|
for updating archives.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Archive Members, Next: Archive Update, Prev: Archives, Up: Archives
|
|
|
|
|
|
11.1 Archive Members as Targets
|
|
|
===============================
|
|
|
|
|
|
An individual member of an archive file can be used as a target or
|
|
|
prerequisite in 'make'. You specify the member named MEMBER in archive
|
|
|
file ARCHIVE as follows:
|
|
|
|
|
|
ARCHIVE(MEMBER)
|
|
|
|
|
|
This construct is available only in targets and prerequisites, not in
|
|
|
recipes! Most programs that you might use in recipes do not support
|
|
|
this syntax and cannot act directly on archive members. Only 'ar' and
|
|
|
other programs specifically designed to operate on archives can do so.
|
|
|
Therefore, valid recipes to update an archive member target probably
|
|
|
must use 'ar'. For example, this rule says to create a member 'hack.o'
|
|
|
in archive 'foolib' by copying the file 'hack.o':
|
|
|
|
|
|
foolib(hack.o) : hack.o
|
|
|
ar cr foolib hack.o
|
|
|
|
|
|
In fact, nearly all archive member targets are updated in just this
|
|
|
way and there is an implicit rule to do it for you. *Please note:* The
|
|
|
'c' flag to 'ar' is required if the archive file does not already exist.
|
|
|
|
|
|
To specify several members in the same archive, you can write all the
|
|
|
member names together between the parentheses. For example:
|
|
|
|
|
|
foolib(hack.o kludge.o)
|
|
|
|
|
|
is equivalent to:
|
|
|
|
|
|
foolib(hack.o) foolib(kludge.o)
|
|
|
|
|
|
You can also use shell-style wildcards in an archive member
|
|
|
reference. *Note Using Wildcard Characters in File Names: Wildcards.
|
|
|
For example, 'foolib(*.o)' expands to all existing members of the
|
|
|
'foolib' archive whose names end in '.o'; perhaps 'foolib(hack.o)
|
|
|
foolib(kludge.o)'.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Archive Update, Next: Archive Pitfalls, Prev: Archive Members, Up: Archives
|
|
|
|
|
|
11.2 Implicit Rule for Archive Member Targets
|
|
|
=============================================
|
|
|
|
|
|
Recall that a target that looks like 'A(M)' stands for the member named
|
|
|
M in the archive file A.
|
|
|
|
|
|
When 'make' looks for an implicit rule for such a target, as a
|
|
|
special feature it considers implicit rules that match '(M)', as well as
|
|
|
those that match the actual target 'A(M)'.
|
|
|
|
|
|
This causes one special rule whose target is '(%)' to match. This
|
|
|
rule updates the target 'A(M)' by copying the file M into the archive.
|
|
|
For example, it will update the archive member target 'foo.a(bar.o)' by
|
|
|
copying the _file_ 'bar.o' into the archive 'foo.a' as a _member_ named
|
|
|
'bar.o'.
|
|
|
|
|
|
When this rule is chained with others, the result is very powerful.
|
|
|
Thus, 'make "foo.a(bar.o)"' (the quotes are needed to protect the '('
|
|
|
and ')' from being interpreted specially by the shell) in the presence
|
|
|
of a file 'bar.c' is enough to cause the following recipe to be run,
|
|
|
even without a makefile:
|
|
|
|
|
|
cc -c bar.c -o bar.o
|
|
|
ar r foo.a bar.o
|
|
|
rm -f bar.o
|
|
|
|
|
|
Here 'make' has envisioned the file 'bar.o' as an intermediate file.
|
|
|
*Note Chains of Implicit Rules: Chained Rules.
|
|
|
|
|
|
Implicit rules such as this one are written using the automatic
|
|
|
variable '$%'. *Note Automatic Variables::.
|
|
|
|
|
|
An archive member name in an archive cannot contain a directory name,
|
|
|
but it may be useful in a makefile to pretend that it does. If you
|
|
|
write an archive member target 'foo.a(dir/file.o)', 'make' will perform
|
|
|
automatic updating with this recipe:
|
|
|
|
|
|
ar r foo.a dir/file.o
|
|
|
|
|
|
which has the effect of copying the file 'dir/file.o' into a member
|
|
|
named 'file.o'. In connection with such usage, the automatic variables
|
|
|
'%D' and '%F' may be useful.
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* Archive Symbols:: How to update archive symbol directories.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Archive Symbols, Prev: Archive Update, Up: Archive Update
|
|
|
|
|
|
11.2.1 Updating Archive Symbol Directories
|
|
|
------------------------------------------
|
|
|
|
|
|
An archive file that is used as a library usually contains a special
|
|
|
member named '__.SYMDEF' that contains a directory of the external
|
|
|
symbol names defined by all the other members. After you update any
|
|
|
other members, you need to update '__.SYMDEF' so that it will summarize
|
|
|
the other members properly. This is done by running the 'ranlib'
|
|
|
program:
|
|
|
|
|
|
ranlib ARCHIVEFILE
|
|
|
|
|
|
Normally you would put this command in the rule for the archive file,
|
|
|
and make all the members of the archive file prerequisites of that rule.
|
|
|
For example,
|
|
|
|
|
|
libfoo.a: libfoo.a(x.o) libfoo.a(y.o) ...
|
|
|
ranlib libfoo.a
|
|
|
|
|
|
The effect of this is to update archive members 'x.o', 'y.o', etc., and
|
|
|
then update the symbol directory member '__.SYMDEF' by running 'ranlib'.
|
|
|
The rules for updating the members are not shown here; most likely you
|
|
|
can omit them and use the implicit rule which copies files into the
|
|
|
archive, as described in the preceding section.
|
|
|
|
|
|
This is not necessary when using the GNU 'ar' program, which updates
|
|
|
the '__.SYMDEF' member automatically.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Archive Pitfalls, Next: Archive Suffix Rules, Prev: Archive Update, Up: Archives
|
|
|
|
|
|
11.3 Dangers When Using Archives
|
|
|
================================
|
|
|
|
|
|
It is important to be careful when using parallel execution (the '-j'
|
|
|
switch; *note Parallel Execution: Parallel.) and archives. If multiple
|
|
|
'ar' commands run at the same time on the same archive file, they will
|
|
|
not know about each other and can corrupt the file.
|
|
|
|
|
|
Possibly a future version of 'make' will provide a mechanism to
|
|
|
circumvent this problem by serializing all recipes that operate on the
|
|
|
same archive file. But for the time being, you must either write your
|
|
|
makefiles to avoid this problem in some other way, or not use '-j'.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Archive Suffix Rules, Prev: Archive Pitfalls, Up: Archives
|
|
|
|
|
|
11.4 Suffix Rules for Archive Files
|
|
|
===================================
|
|
|
|
|
|
You can write a special kind of suffix rule for dealing with archive
|
|
|
files. *Note Suffix Rules::, for a full explanation of suffix rules.
|
|
|
Archive suffix rules are obsolete in GNU 'make', because pattern rules
|
|
|
for archives are a more general mechanism (*note Archive Update::). But
|
|
|
they are retained for compatibility with other 'make's.
|
|
|
|
|
|
To write a suffix rule for archives, you simply write a suffix rule
|
|
|
using the target suffix '.a' (the usual suffix for archive files). For
|
|
|
example, here is the old-fashioned suffix rule to update a library
|
|
|
archive from C source files:
|
|
|
|
|
|
.c.a:
|
|
|
$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o
|
|
|
$(AR) r $@ $*.o
|
|
|
$(RM) $*.o
|
|
|
|
|
|
This works just as if you had written the pattern rule:
|
|
|
|
|
|
(%.o): %.c
|
|
|
$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o
|
|
|
$(AR) r $@ $*.o
|
|
|
$(RM) $*.o
|
|
|
|
|
|
In fact, this is just what 'make' does when it sees a suffix rule
|
|
|
with '.a' as the target suffix. Any double-suffix rule '.X.a' is
|
|
|
converted to a pattern rule with the target pattern '(%.o)' and a
|
|
|
prerequisite pattern of '%.X'.
|
|
|
|
|
|
Since you might want to use '.a' as the suffix for some other kind of
|
|
|
file, 'make' also converts archive suffix rules to pattern rules in the
|
|
|
normal way (*note Suffix Rules::). Thus a double-suffix rule '.X.a'
|
|
|
produces two pattern rules: '(%.o): %.X' and '%.a: %.X'.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Extending make, Next: Integrating make, Prev: Archives, Up: Top
|
|
|
|
|
|
12 Extending GNU 'make'
|
|
|
***********************
|
|
|
|
|
|
GNU 'make' provides many advanced capabilities, including many useful
|
|
|
functions. However, it does not contain a complete programming language
|
|
|
and so it has limitations. Sometimes these limitations can be overcome
|
|
|
through use of the 'shell' function to invoke a separate program,
|
|
|
although this can be inefficient.
|
|
|
|
|
|
In cases where the built-in capabilities of GNU 'make' are
|
|
|
insufficient to your requirements there are two options for extending
|
|
|
'make'. On systems where it's provided, you can utilize GNU Guile as an
|
|
|
embedded scripting language (*note GNU Guile Integration: Guile
|
|
|
Integration.). On systems which support dynamically loadable objects,
|
|
|
you can write your own extension in any language (which can be compiled
|
|
|
into such an object) and load it to provide extended capabilities (*note
|
|
|
The 'load' Directive: load Directive.).
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* Guile Integration:: Using Guile as an embedded scripting language.
|
|
|
* Loading Objects:: Loading dynamic objects as extensions.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Guile Integration, Next: Loading Objects, Prev: Extending make, Up: Extending make
|
|
|
|
|
|
12.1 GNU Guile Integration
|
|
|
==========================
|
|
|
|
|
|
GNU 'make' may be built with support for GNU Guile as an embedded
|
|
|
extension language. Guile implements the Scheme language. A review of
|
|
|
GNU Guile and the Scheme language and its features is beyond the scope
|
|
|
of this manual: see the documentation for GNU Guile and Scheme.
|
|
|
|
|
|
You can determine if 'make' contains support for Guile by examining
|
|
|
the '.FEATURES' variable; it will contain the word GUILE if Guile
|
|
|
support is available.
|
|
|
|
|
|
The Guile integration provides one new 'make' function: 'guile'. The
|
|
|
'guile' function takes one argument which is first expanded by 'make' in
|
|
|
the normal fashion, then passed to the GNU Guile evaluator. The result
|
|
|
of the evaluator is converted into a string and used as the expansion of
|
|
|
the 'guile' function in the makefile.
|
|
|
|
|
|
In addition, GNU 'make' exposes Guile procedures for use in Guile
|
|
|
scripts.
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* Guile Types:: Converting Guile types to 'make' strings.
|
|
|
* Guile Interface:: Invoking 'make' functions from Guile.
|
|
|
* Guile Example:: Example using Guile in 'make'.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Guile Types, Next: Guile Interface, Prev: Guile Integration, Up: Guile Integration
|
|
|
|
|
|
12.1.1 Conversion of Guile Types
|
|
|
--------------------------------
|
|
|
|
|
|
There is only one "data type" in 'make': a string. GNU Guile, on the
|
|
|
other hand, provides a rich variety of different data types. An
|
|
|
important aspect of the interface between 'make' and GNU Guile is the
|
|
|
conversion of Guile data types into 'make' strings.
|
|
|
|
|
|
This conversion is relevant in two places: when a makefile invokes
|
|
|
the 'guile' function to evaluate a Guile expression, the result of that
|
|
|
evaluation must be converted into a make string so it can be further
|
|
|
evaluated by 'make'. And secondly, when a Guile script invokes one of
|
|
|
the procedures exported by 'make' the argument provided to the procedure
|
|
|
must be converted into a string.
|
|
|
|
|
|
The conversion of Guile types into 'make' strings is as below:
|
|
|
|
|
|
'#f'
|
|
|
False is converted into the empty string: in 'make' conditionals
|
|
|
the empty string is considered false.
|
|
|
|
|
|
'#t'
|
|
|
True is converted to the string '#t': in 'make' conditionals any
|
|
|
non-empty string is considered true.
|
|
|
|
|
|
'symbol'
|
|
|
'number'
|
|
|
A symbol or number is converted into the string representation of
|
|
|
that symbol or number.
|
|
|
|
|
|
'character'
|
|
|
A printable character is converted to the same character.
|
|
|
|
|
|
'string'
|
|
|
A string containing only printable characters is converted to the
|
|
|
same string.
|
|
|
|
|
|
'list'
|
|
|
A list is converted recursively according to the above rules. This
|
|
|
implies that any structured list will be flattened (that is, a
|
|
|
result of ''(a b (c d) e)' will be converted to the 'make' string
|
|
|
'a b c d e').
|
|
|
|
|
|
'other'
|
|
|
Any other Guile type results in an error. In future versions of
|
|
|
'make', other Guile types may be converted.
|
|
|
|
|
|
The translation of '#f' (to the empty string) and '#t' (to the
|
|
|
non-empty string '#t') is designed to allow you to use Guile boolean
|
|
|
results directly as 'make' boolean conditions. For example:
|
|
|
|
|
|
$(if $(guile (access? "myfile" R_OK)),$(info myfile exists))
|
|
|
|
|
|
As a consequence of these conversion rules you must consider the
|
|
|
result of your Guile script, as that result will be converted into a
|
|
|
string and parsed by 'make'. If there is no natural result for the
|
|
|
script (that is, the script exists solely for its side-effects), you
|
|
|
should add '#f' as the final expression in order to avoid syntax errors
|
|
|
in your makefile.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Guile Interface, Next: Guile Example, Prev: Guile Types, Up: Guile Integration
|
|
|
|
|
|
12.1.2 Interfaces from Guile to 'make'
|
|
|
--------------------------------------
|
|
|
|
|
|
In addition to the 'guile' function available in makefiles, 'make'
|
|
|
exposes some procedures for use in your Guile scripts. At startup
|
|
|
'make' creates a new Guile module, 'gnu make', and exports these
|
|
|
procedures as public interfaces from that module:
|
|
|
|
|
|
'gmk-expand'
|
|
|
This procedure takes a single argument which is converted into a
|
|
|
string. The string is expanded by 'make' using normal 'make'
|
|
|
expansion rules. The result of the expansion is converted into a
|
|
|
Guile string and provided as the result of the procedure.
|
|
|
|
|
|
'gmk-eval'
|
|
|
This procedure takes a single argument which is converted into a
|
|
|
string. The string is evaluated by 'make' as if it were a
|
|
|
makefile. This is the same capability available via the 'eval'
|
|
|
function (*note Eval Function::). The result of the 'gmk-eval'
|
|
|
procedure is always the empty string.
|
|
|
|
|
|
Note that 'gmk-eval' is not quite the same as using 'gmk-expand'
|
|
|
with the 'eval' function: in the latter case the evaluated string
|
|
|
will be expanded _twice_; first by 'gmk-expand', then again by the
|
|
|
'eval' function.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Guile Example, Prev: Guile Interface, Up: Guile Integration
|
|
|
|
|
|
12.1.3 Example Using Guile in 'make'
|
|
|
------------------------------------
|
|
|
|
|
|
Here is a very simple example using GNU Guile to manage writing to a
|
|
|
file. These Guile procedures simply open a file, allow writing to the
|
|
|
file (one string per line), and close the file. Note that because we
|
|
|
cannot store complex values such as Guile ports in 'make' variables,
|
|
|
we'll keep the port as a global variable in the Guile interpreter.
|
|
|
|
|
|
You can create Guile functions easily using 'define'/'endef' to
|
|
|
create a Guile script, then use the 'guile' function to internalize it:
|
|
|
|
|
|
define GUILEIO
|
|
|
;; A simple Guile IO library for GNU make
|
|
|
|
|
|
(define MKPORT #f)
|
|
|
|
|
|
(define (mkopen name mode)
|
|
|
(set! MKPORT (open-file name mode))
|
|
|
#f)
|
|
|
|
|
|
(define (mkwrite s)
|
|
|
(display s MKPORT)
|
|
|
(newline MKPORT)
|
|
|
#f)
|
|
|
|
|
|
(define (mkclose)
|
|
|
(close-port MKPORT)
|
|
|
#f)
|
|
|
|
|
|
#f
|
|
|
endef
|
|
|
|
|
|
# Internalize the Guile IO functions
|
|
|
$(guile $(GUILEIO))
|
|
|
|
|
|
If you have a significant amount of Guile support code, you might
|
|
|
consider keeping it in a different file (e.g., 'guileio.scm') and then
|
|
|
loading it in your makefile using the 'guile' function:
|
|
|
|
|
|
$(guile (load "guileio.scm"))
|
|
|
|
|
|
An advantage to this method is that when editing 'guileio.scm', your
|
|
|
editor will understand that this file contains Scheme syntax rather than
|
|
|
makefile syntax.
|
|
|
|
|
|
Now you can use these Guile functions to create files. Suppose you
|
|
|
need to operate on a very large list, which cannot fit on the command
|
|
|
line, but the utility you're using accepts the list as input as well:
|
|
|
|
|
|
prog: $(PREREQS)
|
|
|
@$(guile (mkopen "tmp.out" "w")) \
|
|
|
$(foreach X,$^,$(guile (mkwrite "$(X)"))) \
|
|
|
$(guile (mkclose))
|
|
|
$(LINK) < tmp.out
|
|
|
|
|
|
A more comprehensive suite of file manipulation procedures is
|
|
|
possible of course. You could, for example, maintain multiple output
|
|
|
files at the same time by choosing a symbol for each one and using it as
|
|
|
the key to a hash table, where the value is a port, then returning the
|
|
|
symbol to be stored in a 'make' variable.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Loading Objects, Prev: Guile Integration, Up: Extending make
|
|
|
|
|
|
12.2 Loading Dynamic Objects
|
|
|
============================
|
|
|
|
|
|
Warning: The 'load' directive and extension capability is
|
|
|
considered a "technology preview" in this release of GNU make. We
|
|
|
encourage you to experiment with this feature and we appreciate any
|
|
|
feedback on it. However we cannot guarantee to maintain
|
|
|
backward-compatibility in the next release. Consider using GNU
|
|
|
Guile instead for extending GNU make (*note The 'guile' Function:
|
|
|
Guile Function.).
|
|
|
|
|
|
Many operating systems provide a facility for dynamically loading
|
|
|
compiled objects. If your system provides this facility, GNU 'make' can
|
|
|
make use of it to load dynamic objects at runtime, providing new
|
|
|
capabilities which may then be invoked by your makefile.
|
|
|
|
|
|
The 'load' directive is used to load a dynamic object. Once the
|
|
|
object is loaded, a "setup" function will be invoked to allow the object
|
|
|
to initialize itself and register new facilities with GNU 'make'. A
|
|
|
dynamic object might include new 'make' functions, for example, and the
|
|
|
"setup" function would register them with GNU 'make''s function handling
|
|
|
system.
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* load Directive:: Loading dynamic objects as extensions.
|
|
|
* Remaking Loaded Objects:: How loaded objects get remade.
|
|
|
* Loaded Object API:: Programmatic interface for loaded objects.
|
|
|
* Loaded Object Example:: Example of a loaded object
|
|
|
|
|
|
|
|
|
File: make.info, Node: load Directive, Next: Remaking Loaded Objects, Prev: Loading Objects, Up: Loading Objects
|
|
|
|
|
|
12.2.1 The 'load' Directive
|
|
|
---------------------------
|
|
|
|
|
|
Objects are loaded into GNU 'make' by placing the 'load' directive into
|
|
|
your makefile. The syntax of the 'load' directive is as follows:
|
|
|
|
|
|
load OBJECT-FILE ...
|
|
|
|
|
|
or:
|
|
|
|
|
|
load OBJECT-FILE(SYMBOL-NAME) ...
|
|
|
|
|
|
The file OBJECT-FILE is dynamically loaded by GNU 'make'. If
|
|
|
OBJECT-FILE does not include a directory path then it is first looked
|
|
|
for in the current directory. If it is not found there, or a directory
|
|
|
path is included, then system-specific paths will be searched. If the
|
|
|
load fails for any reason, 'make' will print a message and exit.
|
|
|
|
|
|
If the load succeeds 'make' will invoke an initializing function.
|
|
|
|
|
|
If SYMBOL-NAME is provided, it will be used as the name of the
|
|
|
initializing function.
|
|
|
|
|
|
If no SYMBOL-NAME is provided, the initializing function name is
|
|
|
created by taking the base file name of OBJECT-FILE, up to the first
|
|
|
character which is not a valid symbol name character (alphanumerics and
|
|
|
underscores are valid symbol name characters). To this prefix will be
|
|
|
appended the suffix '_gmk_setup'.
|
|
|
|
|
|
More than one object file may be loaded with a single 'load'
|
|
|
directive, and both forms of 'load' arguments may be used in the same
|
|
|
directive.
|
|
|
|
|
|
The initializing function will be provided the file name and line
|
|
|
number of the invocation of the 'load' operation. It should return a
|
|
|
value of type 'int', which must be '0' on failure and non-'0' on
|
|
|
success. If the return value is '-1', then GNU make will _not_ attempt
|
|
|
to rebuild the object file (*note How Loaded Objects Are Remade:
|
|
|
Remaking Loaded Objects.).
|
|
|
|
|
|
For example:
|
|
|
|
|
|
load ../mk_funcs.so
|
|
|
|
|
|
will load the dynamic object '../mk_funcs.so'. After the object is
|
|
|
loaded, 'make' will invoke the function (assumed to be defined by the
|
|
|
shared object) 'mk_funcs_gmk_setup'.
|
|
|
|
|
|
On the other hand:
|
|
|
|
|
|
load ../mk_funcs.so(init_mk_func)
|
|
|
|
|
|
will load the dynamic object '../mk_funcs.so'. After the object is
|
|
|
loaded, 'make' will invoke the function 'init_mk_func'.
|
|
|
|
|
|
Regardless of how many times an object file appears in a 'load'
|
|
|
directive, it will only be loaded (and its setup function will only be
|
|
|
invoked) once.
|
|
|
|
|
|
After an object has been successfully loaded, its file name is
|
|
|
appended to the '.LOADED' variable.
|
|
|
|
|
|
If you would prefer that failure to load a dynamic object not be
|
|
|
reported as an error, you can use the '-load' directive instead of
|
|
|
'load'. GNU 'make' will not fail and no message will be generated if an
|
|
|
object fails to load. The failed object is not added to the '.LOADED'
|
|
|
variable, which can then be consulted to determine if the load was
|
|
|
successful.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Remaking Loaded Objects, Next: Loaded Object API, Prev: load Directive, Up: Loading Objects
|
|
|
|
|
|
12.2.2 How Loaded Objects Are Remade
|
|
|
------------------------------------
|
|
|
|
|
|
Loaded objects undergo the same re-make procedure as makefiles (*note
|
|
|
How Makefiles Are Remade: Remaking Makefiles.). If any loaded object is
|
|
|
recreated, then 'make' will start from scratch and re-read all the
|
|
|
makefiles, and reload the object files again. It is not necessary for
|
|
|
the loaded object to do anything special to support this.
|
|
|
|
|
|
It's up to the makefile author to provide the rules needed for
|
|
|
rebuilding the loaded object.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Loaded Object API, Next: Loaded Object Example, Prev: Remaking Loaded Objects, Up: Loading Objects
|
|
|
|
|
|
12.2.3 Loaded Object Interface
|
|
|
------------------------------
|
|
|
|
|
|
Warning: For this feature to be useful your extensions will need to
|
|
|
invoke various functions internal to GNU 'make'. The programming
|
|
|
interfaces provided in this release should not be considered
|
|
|
stable: functions may be added, removed, or change calling
|
|
|
signatures or implementations in future versions of GNU 'make'.
|
|
|
|
|
|
To be useful, loaded objects must be able to interact with GNU
|
|
|
'make'. This interaction includes both interfaces the loaded object
|
|
|
provides to makefiles and also interfaces 'make' provides to the loaded
|
|
|
object to manipulate 'make''s operation.
|
|
|
|
|
|
The interface between loaded objects and 'make' is defined by the
|
|
|
'gnumake.h' C header file. All loaded objects written in C should
|
|
|
include this header file. Any loaded object not written in C will need
|
|
|
to implement the interface defined in this header file.
|
|
|
|
|
|
Typically, a loaded object will register one or more new GNU 'make'
|
|
|
functions using the 'gmk_add_function' routine from within its setup
|
|
|
function. The implementations of these 'make' functions may make use of
|
|
|
the 'gmk_expand' and 'gmk_eval' routines to perform their tasks, then
|
|
|
optionally return a string as the result of the function expansion.
|
|
|
|
|
|
Loaded Object Licensing
|
|
|
.......................
|
|
|
|
|
|
Every dynamic extension should define the global symbol
|
|
|
'plugin_is_GPL_compatible' to assert that it has been licensed under a
|
|
|
GPL-compatible license. If this symbol does not exist, 'make' emits a
|
|
|
fatal error and exits when it tries to load your extension.
|
|
|
|
|
|
The declared type of the symbol should be 'int'. It does not need to
|
|
|
be in any allocated section, though. The code merely asserts that the
|
|
|
symbol exists in the global scope. Something like this is enough:
|
|
|
|
|
|
int plugin_is_GPL_compatible;
|
|
|
|
|
|
Data Structures
|
|
|
...............
|
|
|
|
|
|
'gmk_floc'
|
|
|
This structure represents a filename/location pair. It is provided
|
|
|
when defining items, so GNU 'make' can inform the user later where
|
|
|
the definition occurred if necessary.
|
|
|
|
|
|
Registering Functions
|
|
|
.....................
|
|
|
|
|
|
There is currently one way for makefiles to invoke operations provided
|
|
|
by the loaded object: through the 'make' function call interface. A
|
|
|
loaded object can register one or more new functions which may then be
|
|
|
invoked from within the makefile in the same way as any other function.
|
|
|
|
|
|
Use 'gmk_add_function' to create a new 'make' function. Its
|
|
|
arguments are as follows:
|
|
|
|
|
|
'name'
|
|
|
The function name. This is what the makefile should use to invoke
|
|
|
the function. The name must be between 1 and 255 characters long
|
|
|
and it may only contain alphanumeric, period ('.'), dash ('-'), and
|
|
|
underscore ('_') characters. It may not begin with a period.
|
|
|
|
|
|
'func_ptr'
|
|
|
A pointer to a function that 'make' will invoke when it expands the
|
|
|
function in a makefile. This function must be defined by the
|
|
|
loaded object.
|
|
|
|
|
|
'min_args'
|
|
|
The minimum number of arguments the function will accept. Must be
|
|
|
between 0 and 255. GNU 'make' will check this and fail before
|
|
|
invoking 'func_ptr' if the function was invoked with too few
|
|
|
arguments.
|
|
|
|
|
|
'max_args'
|
|
|
The maximum number of arguments the function will accept. Must be
|
|
|
between 0 and 255. GNU 'make' will check this and fail before
|
|
|
invoking 'func_ptr' if the function was invoked with too few
|
|
|
arguments. If the value is 0, then any number of arguments is
|
|
|
accepted. If the value is greater than 0, then it must be greater
|
|
|
than or equal to 'min_args'.
|
|
|
|
|
|
'flags'
|
|
|
Flags that specify how this function will operate; the desired
|
|
|
flags should be OR'd together. If the 'GMK_FUNC_NOEXPAND' flag is
|
|
|
given then the function arguments will not be expanded before the
|
|
|
function is called; otherwise they will be expanded first.
|
|
|
|
|
|
Registered Function Interface
|
|
|
.............................
|
|
|
|
|
|
A function registered with 'make' must match the 'gmk_func_ptr' type.
|
|
|
It will be invoked with three parameters: 'name' (the name of the
|
|
|
function), 'argc' (the number of arguments to the function), and 'argv'
|
|
|
(an array of pointers to arguments to the function). The last pointer
|
|
|
(that is, 'argv[argc]') will be null ('0').
|
|
|
|
|
|
The return value of the function is the result of expanding the
|
|
|
function. If the function expands to nothing the return value may be
|
|
|
null. Otherwise, it must be a pointer to a string created with
|
|
|
'gmk_alloc'. Once the function returns, 'make' owns this string and
|
|
|
will free it when appropriate; it cannot be accessed by the loaded
|
|
|
object.
|
|
|
|
|
|
GNU 'make' Facilities
|
|
|
.....................
|
|
|
|
|
|
There are some facilities exported by GNU 'make' for use by loaded
|
|
|
objects. Typically these would be run from within the setup function
|
|
|
and/or the functions registered via 'gmk_add_function', to retrieve or
|
|
|
modify the data 'make' works with.
|
|
|
|
|
|
'gmk_expand'
|
|
|
This function takes a string and expands it using 'make' expansion
|
|
|
rules. The result of the expansion is returned in a nil-terminated
|
|
|
string buffer. The caller is responsible for calling 'gmk_free'
|
|
|
with a pointer to the returned buffer when done.
|
|
|
|
|
|
'gmk_eval'
|
|
|
This function takes a buffer and evaluates it as a segment of
|
|
|
makefile syntax. This function can be used to define new
|
|
|
variables, new rules, etc. It is equivalent to using the 'eval'
|
|
|
'make' function.
|
|
|
|
|
|
Note that there is a difference between 'gmk_eval' and calling
|
|
|
'gmk_expand' with a string using the 'eval' function: in the latter case
|
|
|
the string will be expanded _twice_; once by 'gmk_expand' and then again
|
|
|
by the 'eval' function. Using 'gmk_eval' the buffer is only expanded
|
|
|
once, at most (as it's read by the 'make' parser).
|
|
|
|
|
|
Memory Management
|
|
|
.................
|
|
|
|
|
|
Some systems allow for different memory management schemes. Thus you
|
|
|
should never pass memory that you've allocated directly to any 'make'
|
|
|
function, nor should you attempt to directly free any memory returned to
|
|
|
you by any 'make' function. Instead, use the 'gmk_alloc' and 'gmk_free'
|
|
|
functions.
|
|
|
|
|
|
In particular, the string returned to 'make' by a function registered
|
|
|
using 'gmk_add_function' _must_ be allocated using 'gmk_alloc', and the
|
|
|
string returned from the 'make' 'gmk_expand' function _must_ be freed
|
|
|
(when no longer needed) using 'gmk_free'.
|
|
|
|
|
|
'gmk_alloc'
|
|
|
Return a pointer to a newly-allocated buffer. This function will
|
|
|
always return a valid pointer; if not enough memory is available
|
|
|
'make' will exit.
|
|
|
|
|
|
'gmk_free'
|
|
|
Free a buffer returned to you by 'make'. Once the 'gmk_free'
|
|
|
function returns the string will no longer be valid.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Loaded Object Example, Prev: Loaded Object API, Up: Loading Objects
|
|
|
|
|
|
12.2.4 Example Loaded Object
|
|
|
----------------------------
|
|
|
|
|
|
Let's suppose we wanted to write a new GNU 'make' function that would
|
|
|
create a temporary file and return its name. We would like our function
|
|
|
to take a prefix as an argument. First we can write the function in a
|
|
|
file 'mk_temp.c':
|
|
|
|
|
|
#include <stdlib.h>
|
|
|
#include <stdlib.h>
|
|
|
#include <stdio.h>
|
|
|
#include <string.h>
|
|
|
#include <unistd.h>
|
|
|
#include <errno.h>
|
|
|
|
|
|
#include <gnumake.h>
|
|
|
|
|
|
int plugin_is_GPL_compatible;
|
|
|
|
|
|
char *
|
|
|
gen_tmpfile(const char *nm, int argc, char **argv)
|
|
|
{
|
|
|
int fd;
|
|
|
|
|
|
/* Compute the size of the filename and allocate space for it. */
|
|
|
int len = strlen (argv[0]) + 6 + 1;
|
|
|
char *buf = gmk_alloc (len);
|
|
|
|
|
|
strcpy (buf, argv[0]);
|
|
|
strcat (buf, "XXXXXX");
|
|
|
|
|
|
fd = mkstemp(buf);
|
|
|
if (fd >= 0)
|
|
|
{
|
|
|
/* Don't leak the file descriptor. */
|
|
|
close (fd);
|
|
|
return buf;
|
|
|
}
|
|
|
|
|
|
/* Failure. */
|
|
|
fprintf (stderr, "mkstemp(%s) failed: %s\n", buf, strerror (errno));
|
|
|
gmk_free (buf);
|
|
|
return NULL;
|
|
|
}
|
|
|
|
|
|
int
|
|
|
mk_temp_gmk_setup ()
|
|
|
{
|
|
|
/* Register the function with make name "mk-temp". */
|
|
|
gmk_add_function ("mk-temp", gen_tmpfile, 1, 1, 1);
|
|
|
return 1;
|
|
|
}
|
|
|
|
|
|
Next, we will write a makefile that can build this shared object,
|
|
|
load it, and use it:
|
|
|
|
|
|
all:
|
|
|
@echo Temporary file: $(mk-temp tmpfile.)
|
|
|
|
|
|
load mk_temp.so
|
|
|
|
|
|
mk_temp.so: mk_temp.c
|
|
|
$(CC) -shared -fPIC -o $ $<
|
|
|
|
|
|
On MS-Windows, due to peculiarities of how shared objects are
|
|
|
produced, the compiler needs to scan the "import library" produced when
|
|
|
building 'make', typically called 'libgnumake-VERSION.dll.a', where
|
|
|
VERSION is the version of the load object API. So the recipe to produce
|
|
|
a shared object will look on Windows like this (assuming the API version
|
|
|
is 1):
|
|
|
|
|
|
mk_temp.dll: mk_temp.c
|
|
|
$(CC) -shared -o $ $< -lgnumake-1
|
|
|
|
|
|
Now when you run 'make' you'll see something like:
|
|
|
|
|
|
$ make
|
|
|
cc -shared -fPIC -o mk_temp.so mk_temp.c
|
|
|
Temporary filename: tmpfile.A7JEwd
|
|
|
|
|
|
|
|
|
File: make.info, Node: Integrating make, Next: Features, Prev: Extending make, Up: Top
|
|
|
|
|
|
13 Integrating GNU 'make'
|
|
|
*************************
|
|
|
|
|
|
GNU 'make' is often one component in a larger system of tools, including
|
|
|
integrated development environments, compiler toolchains, and others.
|
|
|
The role of 'make' is to start commands and determine whether they
|
|
|
succeeded or not: no special integration is needed to accomplish that.
|
|
|
However, sometimes it is convenient to bind 'make' more tightly with
|
|
|
other parts of the system, both higher-level (tools that invoke 'make')
|
|
|
and lower-level (tools that 'make' invokes).
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* Job Slots:: Share job slots with GNU 'make'.
|
|
|
* Terminal Output:: Control output to terminals.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Job Slots, Next: Terminal Output, Prev: Integrating make, Up: Integrating make
|
|
|
|
|
|
13.1 Sharing Job Slots with GNU 'make'
|
|
|
======================================
|
|
|
|
|
|
GNU 'make' has the ability to run multiple recipes in parallel (*note
|
|
|
Parallel Execution: Parallel.) and to cap the total number of parallel
|
|
|
jobs even across recursive invocations of 'make' (*note Communicating
|
|
|
Options to a Sub-'make': Options/Recursion.). Tools that 'make' invokes
|
|
|
which are also able to run multiple operations in parallel, either using
|
|
|
multiple threads or multiple processes, can be enhanced to participate
|
|
|
in GNU 'make''s job management facility to ensure that the total number
|
|
|
of active threads/processes running on the system does not exceed the
|
|
|
maximum number of slots provided to GNU 'make'.
|
|
|
|
|
|
GNU 'make' uses a method called the "jobserver" to control the number
|
|
|
of active jobs across recursive invocations. The actual implementation
|
|
|
of the jobserver varies across different operating systems, but some
|
|
|
fundamental aspects are always true.
|
|
|
|
|
|
First, only command lines that 'make' understands to be recursive
|
|
|
invocations of 'make' (*note How the 'MAKE' Variable Works: MAKE
|
|
|
Variable.) will have access to the jobserver. When writing makefiles
|
|
|
you must be sure to mark the command as recursive (most commonly by
|
|
|
prefixing the command line with the '+' indicator (*note Recursive Use
|
|
|
of 'make': Recursion.).
|
|
|
|
|
|
Second, 'make' will provide information necessary for accessing the
|
|
|
jobserver through the environment to its children, in the 'MAKEFLAGS'
|
|
|
environment variable. Tools which want to participate in the jobserver
|
|
|
protocol will need to parse this environment variable, as described in
|
|
|
subsequent sections.
|
|
|
|
|
|
Third, every command 'make' starts has one implicit job slot reserved
|
|
|
for it before it starts. Any tool which wants to participate in the
|
|
|
jobserver protocol should assume it can always run one job without
|
|
|
having to contact the jobserver at all.
|
|
|
|
|
|
Finally, it's critical that tools that participate in the jobserver
|
|
|
protocol return the exact number of slots they obtained from the
|
|
|
jobserver back to the jobserver before they exit, even under error
|
|
|
conditions. Remember that the implicit job slot should *not* be
|
|
|
returned to the jobserver! Returning too few slots means that those
|
|
|
slots will be lost for the rest of the build process; returning too many
|
|
|
slots means that extra slots will be available. The top-level 'make'
|
|
|
command will print an error message at the end of the build if it
|
|
|
detects an incorrect number of slots available in the jobserver.
|
|
|
|
|
|
As an example, suppose you are implementing a linker which provides
|
|
|
for multithreaded operation. You would like to enhance the linker so
|
|
|
that if it is invoked by GNU 'make' it can participate in the jobserver
|
|
|
protocol to control how many threads are used during link. First you
|
|
|
will need to modify the linker to determine if the 'MAKEFLAGS'
|
|
|
environment variable is set. Next you will need to parse the value of
|
|
|
that variable to determine if the jobserver is available, and how to
|
|
|
access it. If it is available then you can access it to obtain job
|
|
|
slots controlling how much parallelism your tool can use. Once done
|
|
|
your tool must return those job slots back to the jobserver.
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* POSIX Jobserver:: Using the jobserver on POSIX systems.
|
|
|
* Windows Jobserver:: Using the jobserver on Windows systems.
|
|
|
|
|
|
|
|
|
File: make.info, Node: POSIX Jobserver, Next: Windows Jobserver, Prev: Job Slots, Up: Job Slots
|
|
|
|
|
|
13.1.1 POSIX Jobserver Interaction
|
|
|
----------------------------------
|
|
|
|
|
|
On POSIX systems the jobserver is implemented as a simple UNIX pipe.
|
|
|
The pipe will be pre-loaded with one single-character token for each
|
|
|
available job. To obtain an extra slot you must read a single character
|
|
|
from the jobserver pipe; to release a slot you must write a single
|
|
|
character back into the jobserver pipe.
|
|
|
|
|
|
To access the pipe you must parse the 'MAKEFLAGS' variable and look
|
|
|
for the argument string '--jobserver-auth=R,W' where 'R' and 'W' are
|
|
|
non-negative integers representing file descriptors: 'R' is the read
|
|
|
file descriptor and 'W' is the write file descriptor.
|
|
|
|
|
|
It's important that when you release the job slot, you write back the
|
|
|
same character you read from the pipe for that slot. Don't assume that
|
|
|
all tokens are the same character; different characters may have
|
|
|
different meanings to GNU 'make'. The order is not important, since
|
|
|
'make' has no idea in what order jobs will complete anyway.
|
|
|
|
|
|
There are various error conditions you must consider to ensure your
|
|
|
implementation is robust:
|
|
|
|
|
|
* Usually you will have a command-line argument controlling the
|
|
|
parallel operation of your tool. Consider whether your tool should
|
|
|
detect situations where both the jobserver and the command-line
|
|
|
argument are specified, and how it should react.
|
|
|
|
|
|
* If your tool determines that the '--jobserver-auth' option is
|
|
|
available in 'MAKEFLAGS' but that the file descriptors specified
|
|
|
are closed, this means that the calling 'make' process did not
|
|
|
think that your tool was a recursive 'make' invocation (e.g., the
|
|
|
command line was not prefixed with a '+' character). You should
|
|
|
notify your users of this situation.
|
|
|
|
|
|
* Your tool should also examine the first word of the 'MAKEFLAGS'
|
|
|
variable and look for the character 'n'. If this character is
|
|
|
present then 'make' was invoked with the '-n' option and your tool
|
|
|
should stop without performing any operations.
|
|
|
|
|
|
* Your tool should be sure to write back the tokens it read, even
|
|
|
under error conditions. This includes not only errors in your tool
|
|
|
but also outside influences such as interrupts ('SIGINT'), etc.
|
|
|
You may want to install signal handlers to manage this write-back.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Windows Jobserver, Prev: POSIX Jobserver, Up: Job Slots
|
|
|
|
|
|
13.1.2 Windows Jobserver Interaction
|
|
|
------------------------------------
|
|
|
|
|
|
On Windows systems the jobserver is implemented as a named semaphore.
|
|
|
The semaphore will be set with an initial count equal to the number of
|
|
|
available slots; to obtain a slot you must wait on the semaphore (with
|
|
|
or without a timeout). To release a slot, release the semaphore.
|
|
|
|
|
|
To access the semaphore you must parse the 'MAKEFLAGS' variable and
|
|
|
look for the argument string '--jobserver-auth=NAME' where 'NAME' is the
|
|
|
name of the named semaphore. Use this name with 'OpenSemaphore' to
|
|
|
create a handle to the semaphore.
|
|
|
|
|
|
There are various error conditions you must consider to ensure your
|
|
|
implementation is robust:
|
|
|
|
|
|
* Usually you will have a command-line argument controlling the
|
|
|
parallel operation of your tool. Consider whether your tool should
|
|
|
detect situations where both the jobserver and the command-line
|
|
|
argument are specified, and how it should react.
|
|
|
|
|
|
* Your tool should be sure to release the semaphore for the tokens it
|
|
|
read, even under error conditions. This includes not only errors
|
|
|
in your tool but also outside influences such as interrupts
|
|
|
('SIGINT'), etc. You may want to install signal handlers to manage
|
|
|
this write-back.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Terminal Output, Prev: Job Slots, Up: Integrating make
|
|
|
|
|
|
13.2 Synchronized Terminal Output
|
|
|
=================================
|
|
|
|
|
|
Normally GNU 'make' will invoke all commands with access to the same
|
|
|
standard and error outputs that 'make' itself was started with. A
|
|
|
number of tools will detect whether the output is a terminal or
|
|
|
not-a-terminal, and use this information to change the output style.
|
|
|
For example if the output goes to a terminal the tool may add control
|
|
|
characters that set color, or even change the location of the cursor.
|
|
|
If the output is not going to a terminal then these special control
|
|
|
characters are not emitted so that they don't corrupt log files, etc.
|
|
|
|
|
|
The '--output-sync' (*note Output During Parallel Output: Parallel
|
|
|
Output.) option will defeat the terminal detection. When output
|
|
|
synchronization is enabled GNU 'make' arranges for all command output to
|
|
|
be written to a file, so that its output can be written as a block
|
|
|
without interference from other commands. This means that all tools
|
|
|
invoked by 'make' will believe that their output is not going to be
|
|
|
displayed on a terminal, even when it will be (because 'make' will
|
|
|
display it there after the command is completed).
|
|
|
|
|
|
In order to facilitate tools which would like to determine whether or
|
|
|
not their output will be displayed on a terminal, GNU 'make' will set
|
|
|
the 'MAKE_TERMOUT' and 'MAKE_TERMERR' environment variables before
|
|
|
invoking any commands. Tools which would like to determine whether
|
|
|
standard or error output (respectively) will be displayed on a terminal
|
|
|
can check these environment variables to determine if they exist and
|
|
|
contain a non-empty value. If so the tool can assume that the output
|
|
|
will (eventually) be displayed on a terminal. If the variables are not
|
|
|
set or have an empty value, then the tool should fall back to its normal
|
|
|
methods of detecting whether output is going to a terminal or not.
|
|
|
|
|
|
The content of the variables can be parsed to determine the type of
|
|
|
terminal which will be used to display the output.
|
|
|
|
|
|
Similarly, environments which invoke 'make' and would like to capture
|
|
|
the output and eventually display it on a terminal (or some display
|
|
|
which can interpret terminal control characters) can set these variables
|
|
|
before invoking 'make'. GNU 'make' will not modify these environment
|
|
|
variables if they already exist when it starts.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Features, Next: Missing, Prev: Integrating make, Up: Top
|
|
|
|
|
|
14 Features of GNU 'make'
|
|
|
*************************
|
|
|
|
|
|
Here is a summary of the features of GNU 'make', for comparison with and
|
|
|
credit to other versions of 'make'. We consider the features of 'make'
|
|
|
in 4.2 BSD systems as a baseline. If you are concerned with writing
|
|
|
portable makefiles, you should not use the features of 'make' listed
|
|
|
here, nor the ones in *note Missing::.
|
|
|
|
|
|
Many features come from the version of 'make' in System V.
|
|
|
|
|
|
* The 'VPATH' variable and its special meaning. *Note Searching
|
|
|
Directories for Prerequisites: Directory Search. This feature
|
|
|
exists in System V 'make', but is undocumented. It is documented
|
|
|
in 4.3 BSD 'make' (which says it mimics System V's 'VPATH'
|
|
|
feature).
|
|
|
|
|
|
* Included makefiles. *Note Including Other Makefiles: Include.
|
|
|
Allowing multiple files to be included with a single directive is a
|
|
|
GNU extension.
|
|
|
|
|
|
* Variables are read from and communicated via the environment.
|
|
|
*Note Variables from the Environment: Environment.
|
|
|
|
|
|
* Options passed through the variable 'MAKEFLAGS' to recursive
|
|
|
invocations of 'make'. *Note Communicating Options to a
|
|
|
Sub-'make': Options/Recursion.
|
|
|
|
|
|
* The automatic variable '$%' is set to the member name in an archive
|
|
|
reference. *Note Automatic Variables::.
|
|
|
|
|
|
* The automatic variables '$@', '$*', '$<', '$%', and '$?' have
|
|
|
corresponding forms like '$(@F)' and '$(@D)'. We have generalized
|
|
|
this to '$^' as an obvious extension. *Note Automatic Variables::.
|
|
|
|
|
|
* Substitution variable references. *Note Basics of Variable
|
|
|
References: Reference.
|
|
|
|
|
|
* The command line options '-b' and '-m', accepted and ignored. In
|
|
|
System V 'make', these options actually do something.
|
|
|
|
|
|
* Execution of recursive commands to run 'make' via the variable
|
|
|
'MAKE' even if '-n', '-q' or '-t' is specified. *Note Recursive
|
|
|
Use of 'make': Recursion.
|
|
|
|
|
|
* Support for suffix '.a' in suffix rules. *Note Archive Suffix
|
|
|
Rules::. This feature is obsolete in GNU 'make', because the
|
|
|
general feature of rule chaining (*note Chains of Implicit Rules:
|
|
|
Chained Rules.) allows one pattern rule for installing members in
|
|
|
an archive (*note Archive Update::) to be sufficient.
|
|
|
|
|
|
* The arrangement of lines and backslash/newline combinations in
|
|
|
recipes is retained when the recipes are printed, so they appear as
|
|
|
they do in the makefile, except for the stripping of initial
|
|
|
whitespace.
|
|
|
|
|
|
The following features were inspired by various other versions of
|
|
|
'make'. In some cases it is unclear exactly which versions inspired
|
|
|
which others.
|
|
|
|
|
|
* Pattern rules using '%'. This has been implemented in several
|
|
|
versions of 'make'. We're not sure who invented it first, but it's
|
|
|
been spread around a bit. *Note Defining and Redefining Pattern
|
|
|
Rules: Pattern Rules.
|
|
|
|
|
|
* Rule chaining and implicit intermediate files. This was
|
|
|
implemented by Stu Feldman in his version of 'make' for AT&T Eighth
|
|
|
Edition Research Unix, and later by Andrew Hume of AT&T Bell Labs
|
|
|
in his 'mk' program (where he terms it "transitive closure"). We
|
|
|
do not really know if we got this from either of them or thought it
|
|
|
up ourselves at the same time. *Note Chains of Implicit Rules:
|
|
|
Chained Rules.
|
|
|
|
|
|
* The automatic variable '$^' containing a list of all prerequisites
|
|
|
of the current target. We did not invent this, but we have no idea
|
|
|
who did. *Note Automatic Variables::. The automatic variable '$+'
|
|
|
is a simple extension of '$^'.
|
|
|
|
|
|
* The "what if" flag ('-W' in GNU 'make') was (as far as we know)
|
|
|
invented by Andrew Hume in 'mk'. *Note Instead of Executing
|
|
|
Recipes: Instead of Execution.
|
|
|
|
|
|
* The concept of doing several things at once (parallelism) exists in
|
|
|
many incarnations of 'make' and similar programs, though not in the
|
|
|
System V or BSD implementations. *Note Recipe Execution:
|
|
|
Execution.
|
|
|
|
|
|
* A number of different build tools that support parallelism also
|
|
|
support collecting output and displaying as a single block. *Note
|
|
|
Output During Parallel Execution: Parallel Output.
|
|
|
|
|
|
* Modified variable references using pattern substitution come from
|
|
|
SunOS 4. *Note Basics of Variable References: Reference. This
|
|
|
functionality was provided in GNU 'make' by the 'patsubst' function
|
|
|
before the alternate syntax was implemented for compatibility with
|
|
|
SunOS 4. It is not altogether clear who inspired whom, since GNU
|
|
|
'make' had 'patsubst' before SunOS 4 was released.
|
|
|
|
|
|
* The special significance of '+' characters preceding recipe lines
|
|
|
(*note Instead of Executing Recipes: Instead of Execution.) is
|
|
|
mandated by 'IEEE Standard 1003.2-1992' (POSIX.2).
|
|
|
|
|
|
* The '+=' syntax to append to the value of a variable comes from
|
|
|
SunOS 4 'make'. *Note Appending More Text to Variables: Appending.
|
|
|
|
|
|
* The syntax 'ARCHIVE(MEM1 MEM2...)' to list multiple members in a
|
|
|
single archive file comes from SunOS 4 'make'. *Note Archive
|
|
|
Members::.
|
|
|
|
|
|
* The '-include' directive to include makefiles with no error for a
|
|
|
nonexistent file comes from SunOS 4 'make'. (But note that SunOS 4
|
|
|
'make' does not allow multiple makefiles to be specified in one
|
|
|
'-include' directive.) The same feature appears with the name
|
|
|
'sinclude' in SGI 'make' and perhaps others.
|
|
|
|
|
|
* The '!=' shell assignment operator exists in many BSD of 'make' and
|
|
|
is purposefully implemented here to behave identically to those
|
|
|
implementations.
|
|
|
|
|
|
* Various build management tools are implemented using scripting
|
|
|
languages such as Perl or Python and thus provide a natural
|
|
|
embedded scripting language, similar to GNU 'make''s integration of
|
|
|
GNU Guile.
|
|
|
|
|
|
The remaining features are inventions new in GNU 'make':
|
|
|
|
|
|
* Use the '-v' or '--version' option to print version and copyright
|
|
|
information.
|
|
|
|
|
|
* Use the '-h' or '--help' option to summarize the options to 'make'.
|
|
|
|
|
|
* Simply-expanded variables. *Note The Two Flavors of Variables:
|
|
|
Flavors.
|
|
|
|
|
|
* Pass command line variable assignments automatically through the
|
|
|
variable 'MAKE' to recursive 'make' invocations. *Note Recursive
|
|
|
Use of 'make': Recursion.
|
|
|
|
|
|
* Use the '-C' or '--directory' command option to change directory.
|
|
|
*Note Summary of Options: Options Summary.
|
|
|
|
|
|
* Make verbatim variable definitions with 'define'. *Note Defining
|
|
|
Multi-Line Variables: Multi-Line.
|
|
|
|
|
|
* Declare phony targets with the special target '.PHONY'.
|
|
|
|
|
|
Andrew Hume of AT&T Bell Labs implemented a similar feature with a
|
|
|
different syntax in his 'mk' program. This seems to be a case of
|
|
|
parallel discovery. *Note Phony Targets: Phony Targets.
|
|
|
|
|
|
* Manipulate text by calling functions. *Note Functions for
|
|
|
Transforming Text: Functions.
|
|
|
|
|
|
* Use the '-o' or '--old-file' option to pretend a file's
|
|
|
modification-time is old. *Note Avoiding Recompilation of Some
|
|
|
Files: Avoiding Compilation.
|
|
|
|
|
|
* Conditional execution.
|
|
|
|
|
|
This feature has been implemented numerous times in various
|
|
|
versions of 'make'; it seems a natural extension derived from the
|
|
|
features of the C preprocessor and similar macro languages and is
|
|
|
not a revolutionary concept. *Note Conditional Parts of Makefiles:
|
|
|
Conditionals.
|
|
|
|
|
|
* Specify a search path for included makefiles. *Note Including
|
|
|
Other Makefiles: Include.
|
|
|
|
|
|
* Specify extra makefiles to read with an environment variable.
|
|
|
*Note The Variable 'MAKEFILES': MAKEFILES Variable.
|
|
|
|
|
|
* Strip leading sequences of './' from file names, so that './FILE'
|
|
|
and 'FILE' are considered to be the same file.
|
|
|
|
|
|
* Use a special search method for library prerequisites written in
|
|
|
the form '-lNAME'. *Note Directory Search for Link Libraries:
|
|
|
Libraries/Search.
|
|
|
|
|
|
* Allow suffixes for suffix rules (*note Old-Fashioned Suffix Rules:
|
|
|
Suffix Rules.) to contain any characters. In other versions of
|
|
|
'make', they must begin with '.' and not contain any '/'
|
|
|
characters.
|
|
|
|
|
|
* Keep track of the current level of 'make' recursion using the
|
|
|
variable 'MAKELEVEL'. *Note Recursive Use of 'make': Recursion.
|
|
|
|
|
|
* Provide any goals given on the command line in the variable
|
|
|
'MAKECMDGOALS'. *Note Arguments to Specify the Goals: Goals.
|
|
|
|
|
|
* Specify static pattern rules. *Note Static Pattern Rules: Static
|
|
|
Pattern.
|
|
|
|
|
|
* Provide selective 'vpath' search. *Note Searching Directories for
|
|
|
Prerequisites: Directory Search.
|
|
|
|
|
|
* Provide computed variable references. *Note Basics of Variable
|
|
|
References: Reference.
|
|
|
|
|
|
* Update makefiles. *Note How Makefiles Are Remade: Remaking
|
|
|
Makefiles. System V 'make' has a very, very limited form of this
|
|
|
functionality in that it will check out SCCS files for makefiles.
|
|
|
|
|
|
* Various new built-in implicit rules. *Note Catalogue of Built-In
|
|
|
Rules: Catalogue of Rules.
|
|
|
|
|
|
* Load dynamic objects which can modify the behavior of 'make'.
|
|
|
*Note Loading Dynamic Objects: Loading Objects.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Missing, Next: Makefile Conventions, Prev: Features, Up: Top
|
|
|
|
|
|
15 Incompatibilities and Missing Features
|
|
|
*****************************************
|
|
|
|
|
|
The 'make' programs in various other systems support a few features that
|
|
|
are not implemented in GNU 'make'. The POSIX.2 standard ('IEEE Standard
|
|
|
1003.2-1992') which specifies 'make' does not require any of these
|
|
|
features.
|
|
|
|
|
|
* A target of the form 'FILE((ENTRY))' stands for a member of archive
|
|
|
file FILE. The member is chosen, not by name, but by being an
|
|
|
object file which defines the linker symbol ENTRY.
|
|
|
|
|
|
This feature was not put into GNU 'make' because of the
|
|
|
non-modularity of putting knowledge into 'make' of the internal
|
|
|
format of archive file symbol tables. *Note Updating Archive
|
|
|
Symbol Directories: Archive Symbols.
|
|
|
|
|
|
* Suffixes (used in suffix rules) that end with the character '~'
|
|
|
have a special meaning to System V 'make'; they refer to the SCCS
|
|
|
file that corresponds to the file one would get without the '~'.
|
|
|
For example, the suffix rule '.c~.o' would make the file 'N.o' from
|
|
|
the SCCS file 's.N.c'. For complete coverage, a whole series of
|
|
|
such suffix rules is required. *Note Old-Fashioned Suffix Rules:
|
|
|
Suffix Rules.
|
|
|
|
|
|
In GNU 'make', this entire series of cases is handled by two
|
|
|
pattern rules for extraction from SCCS, in combination with the
|
|
|
general feature of rule chaining. *Note Chains of Implicit Rules:
|
|
|
Chained Rules.
|
|
|
|
|
|
* In System V and 4.3 BSD 'make', files found by 'VPATH' search
|
|
|
(*note Searching Directories for Prerequisites: Directory Search.)
|
|
|
have their names changed inside recipes. We feel it is much
|
|
|
cleaner to always use automatic variables and thus make this
|
|
|
feature obsolete.
|
|
|
|
|
|
* In some Unix 'make's, the automatic variable '$*' appearing in the
|
|
|
prerequisites of a rule has the amazingly strange "feature" of
|
|
|
expanding to the full name of the _target of that rule_. We cannot
|
|
|
imagine what went on in the minds of Unix 'make' developers to do
|
|
|
this; it is utterly inconsistent with the normal definition of
|
|
|
'$*'.
|
|
|
|
|
|
* In some Unix 'make's, implicit rule search (*note Using Implicit
|
|
|
Rules: Implicit Rules.) is apparently done for _all_ targets, not
|
|
|
just those without recipes. This means you can do:
|
|
|
|
|
|
foo.o:
|
|
|
cc -c foo.c
|
|
|
|
|
|
and Unix 'make' will intuit that 'foo.o' depends on 'foo.c'.
|
|
|
|
|
|
We feel that such usage is broken. The prerequisite properties of
|
|
|
'make' are well-defined (for GNU 'make', at least), and doing such
|
|
|
a thing simply does not fit the model.
|
|
|
|
|
|
* GNU 'make' does not include any built-in implicit rules for
|
|
|
compiling or preprocessing EFL programs. If we hear of anyone who
|
|
|
is using EFL, we will gladly add them.
|
|
|
|
|
|
* It appears that in SVR4 'make', a suffix rule can be specified with
|
|
|
no recipe, and it is treated as if it had an empty recipe (*note
|
|
|
Empty Recipes::). For example:
|
|
|
|
|
|
.c.a:
|
|
|
|
|
|
will override the built-in '.c.a' suffix rule.
|
|
|
|
|
|
We feel that it is cleaner for a rule without a recipe to always
|
|
|
simply add to the prerequisite list for the target. The above
|
|
|
example can be easily rewritten to get the desired behavior in GNU
|
|
|
'make':
|
|
|
|
|
|
.c.a: ;
|
|
|
|
|
|
* Some versions of 'make' invoke the shell with the '-e' flag, except
|
|
|
under '-k' (*note Testing the Compilation of a Program: Testing.).
|
|
|
The '-e' flag tells the shell to exit as soon as any program it
|
|
|
runs returns a nonzero status. We feel it is cleaner to write each
|
|
|
line of the recipe to stand on its own and not require this special
|
|
|
treatment.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Makefile Conventions, Next: Quick Reference, Prev: Missing, Up: Top
|
|
|
|
|
|
16 Makefile Conventions
|
|
|
***********************
|
|
|
|
|
|
This node describes conventions for writing the Makefiles for GNU
|
|
|
programs. Using Automake will help you write a Makefile that follows
|
|
|
these conventions. For more information on portable Makefiles, see
|
|
|
POSIX and *note Portable Make Programming: (autoconf)Portable Make.
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
* Makefile Basics:: General conventions for Makefiles.
|
|
|
* Utilities in Makefiles:: Utilities to be used in Makefiles.
|
|
|
* Command Variables:: Variables for specifying commands.
|
|
|
* DESTDIR:: Supporting staged installs.
|
|
|
* Directory Variables:: Variables for installation directories.
|
|
|
* Standard Targets:: Standard targets for users.
|
|
|
* Install Command Categories:: Three categories of commands in the 'install'
|
|
|
rule: normal, pre-install and post-install.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Makefile Basics, Next: Utilities in Makefiles, Up: Makefile Conventions
|
|
|
|
|
|
16.1 General Conventions for Makefiles
|
|
|
======================================
|
|
|
|
|
|
Every Makefile should contain this line:
|
|
|
|
|
|
SHELL = /bin/sh
|
|
|
|
|
|
to avoid trouble on systems where the 'SHELL' variable might be
|
|
|
inherited from the environment. (This is never a problem with GNU
|
|
|
'make'.)
|
|
|
|
|
|
Different 'make' programs have incompatible suffix lists and implicit
|
|
|
rules, and this sometimes creates confusion or misbehavior. So it is a
|
|
|
good idea to set the suffix list explicitly using only the suffixes you
|
|
|
need in the particular Makefile, like this:
|
|
|
|
|
|
.SUFFIXES:
|
|
|
.SUFFIXES: .c .o
|
|
|
|
|
|
The first line clears out the suffix list, the second introduces all
|
|
|
suffixes which may be subject to implicit rules in this Makefile.
|
|
|
|
|
|
Don't assume that '.' is in the path for command execution. When you
|
|
|
need to run programs that are a part of your package during the make,
|
|
|
please make sure that it uses './' if the program is built as part of
|
|
|
the make or '$(srcdir)/' if the file is an unchanging part of the source
|
|
|
code. Without one of these prefixes, the current search path is used.
|
|
|
|
|
|
The distinction between './' (the "build directory") and '$(srcdir)/'
|
|
|
(the "source directory") is important because users can build in a
|
|
|
separate directory using the '--srcdir' option to 'configure'. A rule
|
|
|
of the form:
|
|
|
|
|
|
foo.1 : foo.man sedscript
|
|
|
sed -f sedscript foo.man > foo.1
|
|
|
|
|
|
will fail when the build directory is not the source directory, because
|
|
|
'foo.man' and 'sedscript' are in the source directory.
|
|
|
|
|
|
When using GNU 'make', relying on 'VPATH' to find the source file
|
|
|
will work in the case where there is a single dependency file, since the
|
|
|
'make' automatic variable '$<' will represent the source file wherever
|
|
|
it is. (Many versions of 'make' set '$<' only in implicit rules.) A
|
|
|
Makefile target like
|
|
|
|
|
|
foo.o : bar.c
|
|
|
$(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
|
|
|
|
|
|
should instead be written as
|
|
|
|
|
|
foo.o : bar.c
|
|
|
$(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@
|
|
|
|
|
|
in order to allow 'VPATH' to work correctly. When the target has
|
|
|
multiple dependencies, using an explicit '$(srcdir)' is the easiest way
|
|
|
to make the rule work well. For example, the target above for 'foo.1'
|
|
|
is best written as:
|
|
|
|
|
|
foo.1 : foo.man sedscript
|
|
|
sed -f $(srcdir)/sedscript $(srcdir)/foo.man > $@
|
|
|
|
|
|
GNU distributions usually contain some files which are not source
|
|
|
files--for example, Info files, and the output from Autoconf, Automake,
|
|
|
Bison or Flex. Since these files normally appear in the source
|
|
|
directory, they should always appear in the source directory, not in the
|
|
|
build directory. So Makefile rules to update them should put the
|
|
|
updated files in the source directory.
|
|
|
|
|
|
However, if a file does not appear in the distribution, then the
|
|
|
Makefile should not put it in the source directory, because building a
|
|
|
program in ordinary circumstances should not modify the source directory
|
|
|
in any way.
|
|
|
|
|
|
Try to make the build and installation targets, at least (and all
|
|
|
their subtargets) work correctly with a parallel 'make'.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Utilities in Makefiles, Next: Command Variables, Prev: Makefile Basics, Up: Makefile Conventions
|
|
|
|
|
|
16.2 Utilities in Makefiles
|
|
|
===========================
|
|
|
|
|
|
Write the Makefile commands (and any shell scripts, such as 'configure')
|
|
|
to run under 'sh' (both the traditional Bourne shell and the POSIX
|
|
|
shell), not 'csh'. Don't use any special features of 'ksh' or 'bash',
|
|
|
or POSIX features not widely supported in traditional Bourne 'sh'.
|
|
|
|
|
|
The 'configure' script and the Makefile rules for building and
|
|
|
installation should not use any utilities directly except these:
|
|
|
|
|
|
awk cat cmp cp diff echo egrep expr false grep install-info ln ls
|
|
|
mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true
|
|
|
|
|
|
Compression programs such as 'gzip' can be used in the 'dist' rule.
|
|
|
|
|
|
Generally, stick to the widely-supported (usually POSIX-specified)
|
|
|
options and features of these programs. For example, don't use 'mkdir
|
|
|
-p', convenient as it may be, because a few systems don't support it at
|
|
|
all and with others, it is not safe for parallel execution. For a list
|
|
|
of known incompatibilities, see *note Portable Shell Programming:
|
|
|
(autoconf)Portable Shell.
|
|
|
|
|
|
It is a good idea to avoid creating symbolic links in makefiles,
|
|
|
since a few file systems don't support them.
|
|
|
|
|
|
The Makefile rules for building and installation can also use
|
|
|
compilers and related programs, but should do so via 'make' variables so
|
|
|
that the user can substitute alternatives. Here are some of the
|
|
|
programs we mean:
|
|
|
|
|
|
ar bison cc flex install ld ldconfig lex
|
|
|
make makeinfo ranlib texi2dvi yacc
|
|
|
|
|
|
Use the following 'make' variables to run those programs:
|
|
|
|
|
|
$(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX)
|
|
|
$(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC)
|
|
|
|
|
|
When you use 'ranlib' or 'ldconfig', you should make sure nothing bad
|
|
|
happens if the system does not have the program in question. Arrange to
|
|
|
ignore an error from that command, and print a message before the
|
|
|
command to tell the user that failure of this command does not mean a
|
|
|
problem. (The Autoconf 'AC_PROG_RANLIB' macro can help with this.)
|
|
|
|
|
|
If you use symbolic links, you should implement a fallback for
|
|
|
systems that don't have symbolic links.
|
|
|
|
|
|
Additional utilities that can be used via Make variables are:
|
|
|
|
|
|
chgrp chmod chown mknod
|
|
|
|
|
|
It is ok to use other utilities in Makefile portions (or scripts)
|
|
|
intended only for particular systems where you know those utilities
|
|
|
exist.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Command Variables, Next: DESTDIR, Prev: Utilities in Makefiles, Up: Makefile Conventions
|
|
|
|
|
|
16.3 Variables for Specifying Commands
|
|
|
======================================
|
|
|
|
|
|
Makefiles should provide variables for overriding certain commands,
|
|
|
options, and so on.
|
|
|
|
|
|
In particular, you should run most utility programs via variables.
|
|
|
Thus, if you use Bison, have a variable named 'BISON' whose default
|
|
|
value is set with 'BISON = bison', and refer to it with '$(BISON)'
|
|
|
whenever you need to use Bison.
|
|
|
|
|
|
File management utilities such as 'ln', 'rm', 'mv', and so on, need
|
|
|
not be referred to through variables in this way, since users don't need
|
|
|
to replace them with other programs.
|
|
|
|
|
|
Each program-name variable should come with an options variable that
|
|
|
is used to supply options to the program. Append 'FLAGS' to the
|
|
|
program-name variable name to get the options variable name--for
|
|
|
example, 'BISONFLAGS'. (The names 'CFLAGS' for the C compiler, 'YFLAGS'
|
|
|
for yacc, and 'LFLAGS' for lex, are exceptions to this rule, but we keep
|
|
|
them because they are standard.) Use 'CPPFLAGS' in any compilation
|
|
|
command that runs the preprocessor, and use 'LDFLAGS' in any compilation
|
|
|
command that does linking as well as in any direct use of 'ld'.
|
|
|
|
|
|
If there are C compiler options that _must_ be used for proper
|
|
|
compilation of certain files, do not include them in 'CFLAGS'. Users
|
|
|
expect to be able to specify 'CFLAGS' freely themselves. Instead,
|
|
|
arrange to pass the necessary options to the C compiler independently of
|
|
|
'CFLAGS', by writing them explicitly in the compilation commands or by
|
|
|
defining an implicit rule, like this:
|
|
|
|
|
|
CFLAGS = -g
|
|
|
ALL_CFLAGS = -I. $(CFLAGS)
|
|
|
.c.o:
|
|
|
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
|
|
|
|
|
|
Do include the '-g' option in 'CFLAGS', because that is not
|
|
|
_required_ for proper compilation. You can consider it a default that
|
|
|
is only recommended. If the package is set up so that it is compiled
|
|
|
with GCC by default, then you might as well include '-O' in the default
|
|
|
value of 'CFLAGS' as well.
|
|
|
|
|
|
Put 'CFLAGS' last in the compilation command, after other variables
|
|
|
containing compiler options, so the user can use 'CFLAGS' to override
|
|
|
the others.
|
|
|
|
|
|
'CFLAGS' should be used in every invocation of the C compiler, both
|
|
|
those which do compilation and those which do linking.
|
|
|
|
|
|
Every Makefile should define the variable 'INSTALL', which is the
|
|
|
basic command for installing a file into the system.
|
|
|
|
|
|
Every Makefile should also define the variables 'INSTALL_PROGRAM' and
|
|
|
'INSTALL_DATA'. (The default for 'INSTALL_PROGRAM' should be
|
|
|
'$(INSTALL)'; the default for 'INSTALL_DATA' should be '${INSTALL} -m
|
|
|
644'.) Then it should use those variables as the commands for actual
|
|
|
installation, for executables and non-executables respectively. Minimal
|
|
|
use of these variables is as follows:
|
|
|
|
|
|
$(INSTALL_PROGRAM) foo $(bindir)/foo
|
|
|
$(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a
|
|
|
|
|
|
However, it is preferable to support a 'DESTDIR' prefix on the target
|
|
|
files, as explained in the next section.
|
|
|
|
|
|
It is acceptable, but not required, to install multiple files in one
|
|
|
command, with the final argument being a directory, as in:
|
|
|
|
|
|
$(INSTALL_PROGRAM) foo bar baz $(bindir)
|
|
|
|
|
|
|
|
|
File: make.info, Node: DESTDIR, Next: Directory Variables, Prev: Command Variables, Up: Makefile Conventions
|
|
|
|
|
|
16.4 'DESTDIR': Support for Staged Installs
|
|
|
===========================================
|
|
|
|
|
|
'DESTDIR' is a variable prepended to each installed target file, like
|
|
|
this:
|
|
|
|
|
|
$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo
|
|
|
$(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
|
|
|
|
|
|
The 'DESTDIR' variable is specified by the user on the 'make' command
|
|
|
line as an absolute file name. For example:
|
|
|
|
|
|
make DESTDIR=/tmp/stage install
|
|
|
|
|
|
'DESTDIR' should be supported only in the 'install*' and 'uninstall*'
|
|
|
targets, as those are the only targets where it is useful.
|
|
|
|
|
|
If your installation step would normally install '/usr/local/bin/foo'
|
|
|
and '/usr/local/lib/libfoo.a', then an installation invoked as in the
|
|
|
example above would install '/tmp/stage/usr/local/bin/foo' and
|
|
|
'/tmp/stage/usr/local/lib/libfoo.a' instead.
|
|
|
|
|
|
Prepending the variable 'DESTDIR' to each target in this way provides
|
|
|
for "staged installs", where the installed files are not placed directly
|
|
|
into their expected location but are instead copied into a temporary
|
|
|
location ('DESTDIR'). However, installed files maintain their relative
|
|
|
directory structure and any embedded file names will not be modified.
|
|
|
|
|
|
You should not set the value of 'DESTDIR' in your 'Makefile' at all;
|
|
|
then the files are installed into their expected locations by default.
|
|
|
Also, specifying 'DESTDIR' should not change the operation of the
|
|
|
software in any way, so its value should not be included in any file
|
|
|
contents.
|
|
|
|
|
|
'DESTDIR' support is commonly used in package creation. It is also
|
|
|
helpful to users who want to understand what a given package will
|
|
|
install where, and to allow users who don't normally have permissions to
|
|
|
install into protected areas to build and install before gaining those
|
|
|
permissions. Finally, it can be useful with tools such as 'stow', where
|
|
|
code is installed in one place but made to appear to be installed
|
|
|
somewhere else using symbolic links or special mount operations. So, we
|
|
|
strongly recommend GNU packages support 'DESTDIR', though it is not an
|
|
|
absolute requirement.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Directory Variables, Next: Standard Targets, Prev: DESTDIR, Up: Makefile Conventions
|
|
|
|
|
|
16.5 Variables for Installation Directories
|
|
|
===========================================
|
|
|
|
|
|
Installation directories should always be named by variables, so it is
|
|
|
easy to install in a nonstandard place. The standard names for these
|
|
|
variables and the values they should have in GNU packages are described
|
|
|
below. They are based on a standard file system layout; variants of it
|
|
|
are used in GNU/Linux and other modern operating systems.
|
|
|
|
|
|
Installers are expected to override these values when calling 'make'
|
|
|
(e.g., 'make prefix=/usr install') or 'configure' (e.g., 'configure
|
|
|
--prefix=/usr'). GNU packages should not try to guess which value
|
|
|
should be appropriate for these variables on the system they are being
|
|
|
installed onto: use the default settings specified here so that all GNU
|
|
|
packages behave identically, allowing the installer to achieve any
|
|
|
desired layout.
|
|
|
|
|
|
All installation directories, and their parent directories, should be
|
|
|
created (if necessary) before they are installed into.
|
|
|
|
|
|
These first two variables set the root for the installation. All the
|
|
|
other installation directories should be subdirectories of one of these
|
|
|
two, and nothing should be directly installed into these two
|
|
|
directories.
|
|
|
|
|
|
'prefix'
|
|
|
A prefix used in constructing the default values of the variables
|
|
|
listed below. The default value of 'prefix' should be
|
|
|
'/usr/local'. When building the complete GNU system, the prefix
|
|
|
will be empty and '/usr' will be a symbolic link to '/'. (If you
|
|
|
are using Autoconf, write it as '@prefix@'.)
|
|
|
|
|
|
Running 'make install' with a different value of 'prefix' from the
|
|
|
one used to build the program should _not_ recompile the program.
|
|
|
|
|
|
'exec_prefix'
|
|
|
A prefix used in constructing the default values of some of the
|
|
|
variables listed below. The default value of 'exec_prefix' should
|
|
|
be '$(prefix)'. (If you are using Autoconf, write it as
|
|
|
'@exec_prefix@'.)
|
|
|
|
|
|
Generally, '$(exec_prefix)' is used for directories that contain
|
|
|
machine-specific files (such as executables and subroutine
|
|
|
libraries), while '$(prefix)' is used directly for other
|
|
|
directories.
|
|
|
|
|
|
Running 'make install' with a different value of 'exec_prefix' from
|
|
|
the one used to build the program should _not_ recompile the
|
|
|
program.
|
|
|
|
|
|
Executable programs are installed in one of the following
|
|
|
directories.
|
|
|
|
|
|
'bindir'
|
|
|
The directory for installing executable programs that users can
|
|
|
run. This should normally be '/usr/local/bin', but write it as
|
|
|
'$(exec_prefix)/bin'. (If you are using Autoconf, write it as
|
|
|
'@bindir@'.)
|
|
|
|
|
|
'sbindir'
|
|
|
The directory for installing executable programs that can be run
|
|
|
from the shell, but are only generally useful to system
|
|
|
administrators. This should normally be '/usr/local/sbin', but
|
|
|
write it as '$(exec_prefix)/sbin'. (If you are using Autoconf,
|
|
|
write it as '@sbindir@'.)
|
|
|
|
|
|
'libexecdir'
|
|
|
The directory for installing executable programs to be run by other
|
|
|
programs rather than by users. This directory should normally be
|
|
|
'/usr/local/libexec', but write it as '$(exec_prefix)/libexec'.
|
|
|
(If you are using Autoconf, write it as '@libexecdir@'.)
|
|
|
|
|
|
The definition of 'libexecdir' is the same for all packages, so you
|
|
|
should install your data in a subdirectory thereof. Most packages
|
|
|
install their data under '$(libexecdir)/PACKAGE-NAME/', possibly
|
|
|
within additional subdirectories thereof, such as
|
|
|
'$(libexecdir)/PACKAGE-NAME/MACHINE/VERSION'.
|
|
|
|
|
|
Data files used by the program during its execution are divided into
|
|
|
categories in two ways.
|
|
|
|
|
|
* Some files are normally modified by programs; others are never
|
|
|
normally modified (though users may edit some of these).
|
|
|
|
|
|
* Some files are architecture-independent and can be shared by all
|
|
|
machines at a site; some are architecture-dependent and can be
|
|
|
shared only by machines of the same kind and operating system;
|
|
|
others may never be shared between two machines.
|
|
|
|
|
|
This makes for six different possibilities. However, we want to
|
|
|
discourage the use of architecture-dependent files, aside from object
|
|
|
files and libraries. It is much cleaner to make other data files
|
|
|
architecture-independent, and it is generally not hard.
|
|
|
|
|
|
Here are the variables Makefiles should use to specify directories to
|
|
|
put these various kinds of files in:
|
|
|
|
|
|
'datarootdir'
|
|
|
The root of the directory tree for read-only
|
|
|
architecture-independent data files. This should normally be
|
|
|
'/usr/local/share', but write it as '$(prefix)/share'. (If you are
|
|
|
using Autoconf, write it as '@datarootdir@'.) 'datadir''s default
|
|
|
value is based on this variable; so are 'infodir', 'mandir', and
|
|
|
others.
|
|
|
|
|
|
'datadir'
|
|
|
The directory for installing idiosyncratic read-only
|
|
|
architecture-independent data files for this program. This is
|
|
|
usually the same place as 'datarootdir', but we use the two
|
|
|
separate variables so that you can move these program-specific
|
|
|
files without altering the location for Info files, man pages, etc.
|
|
|
|
|
|
This should normally be '/usr/local/share', but write it as
|
|
|
'$(datarootdir)'. (If you are using Autoconf, write it as
|
|
|
'@datadir@'.)
|
|
|
|
|
|
The definition of 'datadir' is the same for all packages, so you
|
|
|
should install your data in a subdirectory thereof. Most packages
|
|
|
install their data under '$(datadir)/PACKAGE-NAME/'.
|
|
|
|
|
|
'sysconfdir'
|
|
|
The directory for installing read-only data files that pertain to a
|
|
|
single machine-that is to say, files for configuring a host.
|
|
|
Mailer and network configuration files, '/etc/passwd', and so forth
|
|
|
belong here. All the files in this directory should be ordinary
|
|
|
ASCII text files. This directory should normally be
|
|
|
'/usr/local/etc', but write it as '$(prefix)/etc'. (If you are
|
|
|
using Autoconf, write it as '@sysconfdir@'.)
|
|
|
|
|
|
Do not install executables here in this directory (they probably
|
|
|
belong in '$(libexecdir)' or '$(sbindir)'). Also do not install
|
|
|
files that are modified in the normal course of their use (programs
|
|
|
whose purpose is to change the configuration of the system
|
|
|
excluded). Those probably belong in '$(localstatedir)'.
|
|
|
|
|
|
'sharedstatedir'
|
|
|
The directory for installing architecture-independent data files
|
|
|
which the programs modify while they run. This should normally be
|
|
|
'/usr/local/com', but write it as '$(prefix)/com'. (If you are
|
|
|
using Autoconf, write it as '@sharedstatedir@'.)
|
|
|
|
|
|
'localstatedir'
|
|
|
The directory for installing data files which the programs modify
|
|
|
while they run, and that pertain to one specific machine. Users
|
|
|
should never need to modify files in this directory to configure
|
|
|
the package's operation; put such configuration information in
|
|
|
separate files that go in '$(datadir)' or '$(sysconfdir)'.
|
|
|
'$(localstatedir)' should normally be '/usr/local/var', but write
|
|
|
it as '$(prefix)/var'. (If you are using Autoconf, write it as
|
|
|
'@localstatedir@'.)
|
|
|
|
|
|
'runstatedir'
|
|
|
The directory for installing data files which the programs modify
|
|
|
while they run, that pertain to one specific machine, and which
|
|
|
need not persist longer than the execution of the program--which is
|
|
|
generally long-lived, for example, until the next reboot. PID
|
|
|
files for system daemons are a typical use. In addition, this
|
|
|
directory should not be cleaned except perhaps at reboot, while the
|
|
|
general '/tmp' ('TMPDIR') may be cleaned arbitrarily. This should
|
|
|
normally be '/var/run', but write it as '$(localstatedir)/run'.
|
|
|
Having it as a separate variable allows the use of '/run' if
|
|
|
desired, for example. (If you are using Autoconf 2.70 or later,
|
|
|
write it as '@runstatedir@'.)
|
|
|
|
|
|
These variables specify the directory for installing certain specific
|
|
|
types of files, if your program has them. Every GNU package should have
|
|
|
Info files, so every program needs 'infodir', but not all need 'libdir'
|
|
|
or 'lispdir'.
|
|
|
|
|
|
'includedir'
|
|
|
The directory for installing header files to be included by user
|
|
|
programs with the C '#include' preprocessor directive. This should
|
|
|
normally be '/usr/local/include', but write it as
|
|
|
'$(prefix)/include'. (If you are using Autoconf, write it as
|
|
|
'@includedir@'.)
|
|
|
|
|
|
Most compilers other than GCC do not look for header files in
|
|
|
directory '/usr/local/include'. So installing the header files
|
|
|
this way is only useful with GCC. Sometimes this is not a problem
|
|
|
because some libraries are only really intended to work with GCC.
|
|
|
But some libraries are intended to work with other compilers. They
|
|
|
should install their header files in two places, one specified by
|
|
|
'includedir' and one specified by 'oldincludedir'.
|
|
|
|
|
|
'oldincludedir'
|
|
|
The directory for installing '#include' header files for use with
|
|
|
compilers other than GCC. This should normally be '/usr/include'.
|
|
|
(If you are using Autoconf, you can write it as '@oldincludedir@'.)
|
|
|
|
|
|
The Makefile commands should check whether the value of
|
|
|
'oldincludedir' is empty. If it is, they should not try to use it;
|
|
|
they should cancel the second installation of the header files.
|
|
|
|
|
|
A package should not replace an existing header in this directory
|
|
|
unless the header came from the same package. Thus, if your Foo
|
|
|
package provides a header file 'foo.h', then it should install the
|
|
|
header file in the 'oldincludedir' directory if either (1) there is
|
|
|
no 'foo.h' there or (2) the 'foo.h' that exists came from the Foo
|
|
|
package.
|
|
|
|
|
|
To tell whether 'foo.h' came from the Foo package, put a magic
|
|
|
string in the file--part of a comment--and 'grep' for that string.
|
|
|
|
|
|
'docdir'
|
|
|
The directory for installing documentation files (other than Info)
|
|
|
for this package. By default, it should be
|
|
|
'/usr/local/share/doc/YOURPKG', but it should be written as
|
|
|
'$(datarootdir)/doc/YOURPKG'. (If you are using Autoconf, write it
|
|
|
as '@docdir@'.) The YOURPKG subdirectory, which may include a
|
|
|
version number, prevents collisions among files with common names,
|
|
|
such as 'README'.
|
|
|
|
|
|
'infodir'
|
|
|
The directory for installing the Info files for this package. By
|
|
|
default, it should be '/usr/local/share/info', but it should be
|
|
|
written as '$(datarootdir)/info'. (If you are using Autoconf,
|
|
|
write it as '@infodir@'.) 'infodir' is separate from 'docdir' for
|
|
|
compatibility with existing practice.
|
|
|
|
|
|
'htmldir'
|
|
|
'dvidir'
|
|
|
'pdfdir'
|
|
|
'psdir'
|
|
|
Directories for installing documentation files in the particular
|
|
|
format. They should all be set to '$(docdir)' by default. (If you
|
|
|
are using Autoconf, write them as '@htmldir@', '@dvidir@', etc.)
|
|
|
Packages which supply several translations of their documentation
|
|
|
should install them in '$(htmldir)/'LL, '$(pdfdir)/'LL, etc. where
|
|
|
LL is a locale abbreviation such as 'en' or 'pt_BR'.
|
|
|
|
|
|
'libdir'
|
|
|
The directory for object files and libraries of object code. Do
|
|
|
not install executables here, they probably ought to go in
|
|
|
'$(libexecdir)' instead. The value of 'libdir' should normally be
|
|
|
'/usr/local/lib', but write it as '$(exec_prefix)/lib'. (If you
|
|
|
are using Autoconf, write it as '@libdir@'.)
|
|
|
|
|
|
'lispdir'
|
|
|
The directory for installing any Emacs Lisp files in this package.
|
|
|
By default, it should be '/usr/local/share/emacs/site-lisp', but it
|
|
|
should be written as '$(datarootdir)/emacs/site-lisp'.
|
|
|
|
|
|
If you are using Autoconf, write the default as '@lispdir@'. In
|
|
|
order to make '@lispdir@' work, you need the following lines in
|
|
|
your 'configure.ac' file:
|
|
|
|
|
|
lispdir='${datarootdir}/emacs/site-lisp'
|
|
|
AC_SUBST(lispdir)
|
|
|
|
|
|
'localedir'
|
|
|
The directory for installing locale-specific message catalogs for
|
|
|
this package. By default, it should be '/usr/local/share/locale',
|
|
|
but it should be written as '$(datarootdir)/locale'. (If you are
|
|
|
using Autoconf, write it as '@localedir@'.) This directory usually
|
|
|
has a subdirectory per locale.
|
|
|
|
|
|
Unix-style man pages are installed in one of the following:
|
|
|
|
|
|
'mandir'
|
|
|
The top-level directory for installing the man pages (if any) for
|
|
|
this package. It will normally be '/usr/local/share/man', but you
|
|
|
should write it as '$(datarootdir)/man'. (If you are using
|
|
|
Autoconf, write it as '@mandir@'.)
|
|
|
|
|
|
'man1dir'
|
|
|
The directory for installing section 1 man pages. Write it as
|
|
|
'$(mandir)/man1'.
|
|
|
'man2dir'
|
|
|
The directory for installing section 2 man pages. Write it as
|
|
|
'$(mandir)/man2'
|
|
|
'...'
|
|
|
|
|
|
*Don't make the primary documentation for any GNU software be a man
|
|
|
page. Write a manual in Texinfo instead. Man pages are just for
|
|
|
the sake of people running GNU software on Unix, which is a
|
|
|
secondary application only.*
|
|
|
|
|
|
'manext'
|
|
|
The file name extension for the installed man page. This should
|
|
|
contain a period followed by the appropriate digit; it should
|
|
|
normally be '.1'.
|
|
|
|
|
|
'man1ext'
|
|
|
The file name extension for installed section 1 man pages.
|
|
|
'man2ext'
|
|
|
The file name extension for installed section 2 man pages.
|
|
|
'...'
|
|
|
Use these names instead of 'manext' if the package needs to install
|
|
|
man pages in more than one section of the manual.
|
|
|
|
|
|
And finally, you should set the following variable:
|
|
|
|
|
|
'srcdir'
|
|
|
The directory for the sources being compiled. The value of this
|
|
|
variable is normally inserted by the 'configure' shell script. (If
|
|
|
you are using Autoconf, use 'srcdir = @srcdir@'.)
|
|
|
|
|
|
For example:
|
|
|
|
|
|
# Common prefix for installation directories.
|
|
|
# NOTE: This directory must exist when you start the install.
|
|
|
prefix = /usr/local
|
|
|
datarootdir = $(prefix)/share
|
|
|
datadir = $(datarootdir)
|
|
|
exec_prefix = $(prefix)
|
|
|
# Where to put the executable for the command 'gcc'.
|
|
|
bindir = $(exec_prefix)/bin
|
|
|
# Where to put the directories used by the compiler.
|
|
|
libexecdir = $(exec_prefix)/libexec
|
|
|
# Where to put the Info files.
|
|
|
infodir = $(datarootdir)/info
|
|
|
|
|
|
If your program installs a large number of files into one of the
|
|
|
standard user-specified directories, it might be useful to group them
|
|
|
into a subdirectory particular to that program. If you do this, you
|
|
|
should write the 'install' rule to create these subdirectories.
|
|
|
|
|
|
Do not expect the user to include the subdirectory name in the value
|
|
|
of any of the variables listed above. The idea of having a uniform set
|
|
|
of variable names for installation directories is to enable the user to
|
|
|
specify the exact same values for several different GNU packages. In
|
|
|
order for this to be useful, all the packages must be designed so that
|
|
|
they will work sensibly when the user does so.
|
|
|
|
|
|
At times, not all of these variables may be implemented in the
|
|
|
current release of Autoconf and/or Automake; but as of Autoconf 2.60, we
|
|
|
believe all of them are. When any are missing, the descriptions here
|
|
|
serve as specifications for what Autoconf will implement. As a
|
|
|
programmer, you can either use a development version of Autoconf or
|
|
|
avoid using these variables until a stable release is made which
|
|
|
supports them.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Standard Targets, Next: Install Command Categories, Prev: Directory Variables, Up: Makefile Conventions
|
|
|
|
|
|
16.6 Standard Targets for Users
|
|
|
===============================
|
|
|
|
|
|
All GNU programs should have the following targets in their Makefiles:
|
|
|
|
|
|
'all'
|
|
|
Compile the entire program. This should be the default target.
|
|
|
This target need not rebuild any documentation files; Info files
|
|
|
should normally be included in the distribution, and DVI (and other
|
|
|
documentation format) files should be made only when explicitly
|
|
|
asked for.
|
|
|
|
|
|
By default, the Make rules should compile and link with '-g', so
|
|
|
that executable programs have debugging symbols. Otherwise, you
|
|
|
are essentially helpless in the face of a crash, and it is often
|
|
|
far from easy to reproduce with a fresh build.
|
|
|
|
|
|
'install'
|
|
|
Compile the program and copy the executables, libraries, and so on
|
|
|
to the file names where they should reside for actual use. If
|
|
|
there is a simple test to verify that a program is properly
|
|
|
installed, this target should run that test.
|
|
|
|
|
|
Do not strip executables when installing them. This helps eventual
|
|
|
debugging that may be needed later, and nowadays disk space is
|
|
|
cheap and dynamic loaders typically ensure debug sections are not
|
|
|
loaded during normal execution. Users that need stripped binaries
|
|
|
may invoke the 'install-strip' target to do that.
|
|
|
|
|
|
If possible, write the 'install' target rule so that it does not
|
|
|
modify anything in the directory where the program was built,
|
|
|
provided 'make all' has just been done. This is convenient for
|
|
|
building the program under one user name and installing it under
|
|
|
another.
|
|
|
|
|
|
The commands should create all the directories in which files are
|
|
|
to be installed, if they don't already exist. This includes the
|
|
|
directories specified as the values of the variables 'prefix' and
|
|
|
'exec_prefix', as well as all subdirectories that are needed. One
|
|
|
way to do this is by means of an 'installdirs' target as described
|
|
|
below.
|
|
|
|
|
|
Use '-' before any command for installing a man page, so that
|
|
|
'make' will ignore any errors. This is in case there are systems
|
|
|
that don't have the Unix man page documentation system installed.
|
|
|
|
|
|
The way to install Info files is to copy them into '$(infodir)'
|
|
|
with '$(INSTALL_DATA)' (*note Command Variables::), and then run
|
|
|
the 'install-info' program if it is present. 'install-info' is a
|
|
|
program that edits the Info 'dir' file to add or update the menu
|
|
|
entry for the given Info file; it is part of the Texinfo package.
|
|
|
|
|
|
Here is a sample rule to install an Info file that also tries to
|
|
|
handle some additional situations, such as 'install-info' not being
|
|
|
present.
|
|
|
|
|
|
do-install-info: foo.info installdirs
|
|
|
$(NORMAL_INSTALL)
|
|
|
# Prefer an info file in . to one in srcdir.
|
|
|
if test -f foo.info; then d=.; \
|
|
|
else d="$(srcdir)"; fi; \
|
|
|
$(INSTALL_DATA) $$d/foo.info \
|
|
|
"$(DESTDIR)$(infodir)/foo.info"
|
|
|
# Run install-info only if it exists.
|
|
|
# Use 'if' instead of just prepending '-' to the
|
|
|
# line so we notice real errors from install-info.
|
|
|
# Use '$(SHELL) -c' because some shells do not
|
|
|
# fail gracefully when there is an unknown command.
|
|
|
$(POST_INSTALL)
|
|
|
if $(SHELL) -c 'install-info --version' \
|
|
|
>/dev/null 2>&1; then \
|
|
|
install-info --dir-file="$(DESTDIR)$(infodir)/dir" \
|
|
|
"$(DESTDIR)$(infodir)/foo.info"; \
|
|
|
else true; fi
|
|
|
|
|
|
When writing the 'install' target, you must classify all the
|
|
|
commands into three categories: normal ones, "pre-installation"
|
|
|
commands and "post-installation" commands. *Note Install Command
|
|
|
Categories::.
|
|
|
|
|
|
'install-html'
|
|
|
'install-dvi'
|
|
|
'install-pdf'
|
|
|
'install-ps'
|
|
|
These targets install documentation in formats other than Info;
|
|
|
they're intended to be called explicitly by the person installing
|
|
|
the package, if that format is desired. GNU prefers Info files, so
|
|
|
these must be installed by the 'install' target.
|
|
|
|
|
|
When you have many documentation files to install, we recommend
|
|
|
that you avoid collisions and clutter by arranging for these
|
|
|
targets to install in subdirectories of the appropriate
|
|
|
installation directory, such as 'htmldir'. As one example, if your
|
|
|
package has multiple manuals, and you wish to install HTML
|
|
|
documentation with many files (such as the "split" mode output by
|
|
|
'makeinfo --html'), you'll certainly want to use subdirectories, or
|
|
|
two nodes with the same name in different manuals will overwrite
|
|
|
each other.
|
|
|
|
|
|
Please make these 'install-FORMAT' targets invoke the commands for
|
|
|
the FORMAT target, for example, by making FORMAT a dependency.
|
|
|
|
|
|
'uninstall'
|
|
|
Delete all the installed files--the copies that the 'install' and
|
|
|
'install-*' targets create.
|
|
|
|
|
|
This rule should not modify the directories where compilation is
|
|
|
done, only the directories where files are installed.
|
|
|
|
|
|
The uninstallation commands are divided into three categories, just
|
|
|
like the installation commands. *Note Install Command
|
|
|
Categories::.
|
|
|
|
|
|
'install-strip'
|
|
|
Like 'install', but strip the executable files while installing
|
|
|
them. In simple cases, this target can use the 'install' target in
|
|
|
a simple way:
|
|
|
|
|
|
install-strip:
|
|
|
$(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
|
|
|
install
|
|
|
|
|
|
But if the package installs scripts as well as real executables,
|
|
|
the 'install-strip' target can't just refer to the 'install'
|
|
|
target; it has to strip the executables but not the scripts.
|
|
|
|
|
|
'install-strip' should not strip the executables in the build
|
|
|
directory which are being copied for installation. It should only
|
|
|
strip the copies that are installed.
|
|
|
|
|
|
Normally we do not recommend stripping an executable unless you are
|
|
|
sure the program has no bugs. However, it can be reasonable to
|
|
|
install a stripped executable for actual execution while saving the
|
|
|
unstripped executable elsewhere in case there is a bug.
|
|
|
|
|
|
'clean'
|
|
|
Delete all files in the current directory that are normally created
|
|
|
by building the program. Also delete files in other directories if
|
|
|
they are created by this makefile. However, don't delete the files
|
|
|
that record the configuration. Also preserve files that could be
|
|
|
made by building, but normally aren't because the distribution
|
|
|
comes with them. There is no need to delete parent directories
|
|
|
that were created with 'mkdir -p', since they could have existed
|
|
|
anyway.
|
|
|
|
|
|
Delete '.dvi' files here if they are not part of the distribution.
|
|
|
|
|
|
'distclean'
|
|
|
Delete all files in the current directory (or created by this
|
|
|
makefile) that are created by configuring or building the program.
|
|
|
If you have unpacked the source and built the program without
|
|
|
creating any other files, 'make distclean' should leave only the
|
|
|
files that were in the distribution. However, there is no need to
|
|
|
delete parent directories that were created with 'mkdir -p', since
|
|
|
they could have existed anyway.
|
|
|
|
|
|
'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.
|
|
|
|
|
|
'maintainer-clean'
|
|
|
Delete almost everything that can be reconstructed with this
|
|
|
Makefile. This typically includes everything deleted by
|
|
|
'distclean', plus more: C source files produced by Bison, tags
|
|
|
tables, Info files, and so on.
|
|
|
|
|
|
The reason we say "almost everything" is that running the command
|
|
|
'make maintainer-clean' should not delete 'configure' even if
|
|
|
'configure' can be remade using a rule in the Makefile. More
|
|
|
generally, 'make maintainer-clean' should not delete anything that
|
|
|
needs to exist in order to run 'configure' and then begin to build
|
|
|
the program. Also, there is no need to delete parent directories
|
|
|
that were created with 'mkdir -p', since they could have existed
|
|
|
anyway. These are the only exceptions; 'maintainer-clean' should
|
|
|
delete everything else that can be rebuilt.
|
|
|
|
|
|
The 'maintainer-clean' target is intended to be used by a
|
|
|
maintainer of the package, not by ordinary users. You may need
|
|
|
special tools to reconstruct some of the files that 'make
|
|
|
maintainer-clean' deletes. Since these files are normally included
|
|
|
in the distribution, we don't take care to make them easy to
|
|
|
reconstruct. If you find you need to unpack the full distribution
|
|
|
again, don't blame us.
|
|
|
|
|
|
To help make users aware of this, the commands for the special
|
|
|
'maintainer-clean' target should start with these two:
|
|
|
|
|
|
@echo 'This command is intended for maintainers to use; it'
|
|
|
@echo 'deletes files that may need special tools to rebuild.'
|
|
|
|
|
|
'TAGS'
|
|
|
Update a tags table for this program.
|
|
|
|
|
|
'info'
|
|
|
Generate any Info files needed. The best way to write the rules is
|
|
|
as follows:
|
|
|
|
|
|
info: foo.info
|
|
|
|
|
|
foo.info: foo.texi chap1.texi chap2.texi
|
|
|
$(MAKEINFO) $(srcdir)/foo.texi
|
|
|
|
|
|
You must define the variable 'MAKEINFO' in the Makefile. It should
|
|
|
run the 'makeinfo' program, which is part of the Texinfo
|
|
|
distribution.
|
|
|
|
|
|
Normally a GNU distribution comes with Info files, and that means
|
|
|
the Info files are present in the source directory. Therefore, the
|
|
|
Make rule for an info file should update it in the source
|
|
|
directory. When users build the package, ordinarily Make will not
|
|
|
update the Info files because they will already be up to date.
|
|
|
|
|
|
'dvi'
|
|
|
'html'
|
|
|
'pdf'
|
|
|
'ps'
|
|
|
Generate documentation files in the given format. These targets
|
|
|
should always exist, but any or all can be a no-op if the given
|
|
|
output format cannot be generated. These targets should not be
|
|
|
dependencies of the 'all' target; the user must manually invoke
|
|
|
them.
|
|
|
|
|
|
Here's an example rule for generating DVI files from Texinfo:
|
|
|
|
|
|
dvi: foo.dvi
|
|
|
|
|
|
foo.dvi: foo.texi chap1.texi chap2.texi
|
|
|
$(TEXI2DVI) $(srcdir)/foo.texi
|
|
|
|
|
|
You must define the variable 'TEXI2DVI' in the Makefile. It should
|
|
|
run the program 'texi2dvi', which is part of the Texinfo
|
|
|
distribution. ('texi2dvi' uses TeX to do the real work of
|
|
|
formatting. TeX is not distributed with Texinfo.) Alternatively,
|
|
|
write only the dependencies, and allow GNU 'make' to provide the
|
|
|
command.
|
|
|
|
|
|
Here's another example, this one for generating HTML from Texinfo:
|
|
|
|
|
|
html: foo.html
|
|
|
|
|
|
foo.html: foo.texi chap1.texi chap2.texi
|
|
|
$(TEXI2HTML) $(srcdir)/foo.texi
|
|
|
|
|
|
Again, you would define the variable 'TEXI2HTML' in the Makefile;
|
|
|
for example, it might run 'makeinfo --no-split --html' ('makeinfo'
|
|
|
is part of the Texinfo distribution).
|
|
|
|
|
|
'dist'
|
|
|
Create a distribution tar file for this program. The tar file
|
|
|
should be set up so that the file names in the tar file start with
|
|
|
a subdirectory name which is the name of the package it is a
|
|
|
distribution for. This name can include the version number.
|
|
|
|
|
|
For example, the distribution tar file of GCC version 1.40 unpacks
|
|
|
into a subdirectory named 'gcc-1.40'.
|
|
|
|
|
|
The easiest way to do this is to create a subdirectory
|
|
|
appropriately named, use 'ln' or 'cp' to install the proper files
|
|
|
in it, and then 'tar' that subdirectory.
|
|
|
|
|
|
Compress the tar file with 'gzip'. For example, the actual
|
|
|
distribution file for GCC version 1.40 is called 'gcc-1.40.tar.gz'.
|
|
|
It is ok to support other free compression formats as well.
|
|
|
|
|
|
The 'dist' target should explicitly depend on all non-source files
|
|
|
that are in the distribution, to make sure they are up to date in
|
|
|
the distribution. *Note Making Releases: (standards)Releases.
|
|
|
|
|
|
'check'
|
|
|
Perform self-tests (if any). The user must build the program
|
|
|
before running the tests, but need not install the program; you
|
|
|
should write the self-tests so that they work when the program is
|
|
|
built but not installed.
|
|
|
|
|
|
The following targets are suggested as conventional names, for
|
|
|
programs in which they are useful.
|
|
|
|
|
|
'installcheck'
|
|
|
Perform installation tests (if any). The user must build and
|
|
|
install the program before running the tests. You should not
|
|
|
assume that '$(bindir)' is in the search path.
|
|
|
|
|
|
'installdirs'
|
|
|
It's useful to add a target named 'installdirs' to create the
|
|
|
directories where files are installed, and their parent
|
|
|
directories. There is a script called 'mkinstalldirs' which is
|
|
|
convenient for this; you can find it in the Gnulib package. You
|
|
|
can use a rule like this:
|
|
|
|
|
|
# Make sure all installation directories (e.g. $(bindir))
|
|
|
# actually exist by making them if necessary.
|
|
|
installdirs: mkinstalldirs
|
|
|
$(srcdir)/mkinstalldirs $(bindir) $(datadir) \
|
|
|
$(libdir) $(infodir) \
|
|
|
$(mandir)
|
|
|
|
|
|
or, if you wish to support 'DESTDIR' (strongly encouraged),
|
|
|
|
|
|
# Make sure all installation directories (e.g. $(bindir))
|
|
|
# actually exist by making them if necessary.
|
|
|
installdirs: mkinstalldirs
|
|
|
$(srcdir)/mkinstalldirs \
|
|
|
$(DESTDIR)$(bindir) $(DESTDIR)$(datadir) \
|
|
|
$(DESTDIR)$(libdir) $(DESTDIR)$(infodir) \
|
|
|
$(DESTDIR)$(mandir)
|
|
|
|
|
|
This rule should not modify the directories where compilation is
|
|
|
done. It should do nothing but create installation directories.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Install Command Categories, Prev: Standard Targets, Up: Makefile Conventions
|
|
|
|
|
|
16.7 Install Command Categories
|
|
|
===============================
|
|
|
|
|
|
When writing the 'install' target, you must classify all the commands
|
|
|
into three categories: normal ones, "pre-installation" commands and
|
|
|
"post-installation" commands.
|
|
|
|
|
|
Normal commands move files into their proper places, and set their
|
|
|
modes. They may not alter any files except the ones that come entirely
|
|
|
from the package they belong to.
|
|
|
|
|
|
Pre-installation and post-installation commands may alter other
|
|
|
files; in particular, they can edit global configuration files or data
|
|
|
bases.
|
|
|
|
|
|
Pre-installation commands are typically executed before the normal
|
|
|
commands, and post-installation commands are typically run after the
|
|
|
normal commands.
|
|
|
|
|
|
The most common use for a post-installation command is to run
|
|
|
'install-info'. This cannot be done with a normal command, since it
|
|
|
alters a file (the Info directory) which does not come entirely and
|
|
|
solely from the package being installed. It is a post-installation
|
|
|
command because it needs to be done after the normal command which
|
|
|
installs the package's Info files.
|
|
|
|
|
|
Most programs don't need any pre-installation commands, but we have
|
|
|
the feature just in case it is needed.
|
|
|
|
|
|
To classify the commands in the 'install' rule into these three
|
|
|
categories, insert "category lines" among them. A category line
|
|
|
specifies the category for the commands that follow.
|
|
|
|
|
|
A category line consists of a tab and a reference to a special Make
|
|
|
variable, plus an optional comment at the end. There are three
|
|
|
variables you can use, one for each category; the variable name
|
|
|
specifies the category. Category lines are no-ops in ordinary execution
|
|
|
because these three Make variables are normally undefined (and you
|
|
|
_should not_ define them in the makefile).
|
|
|
|
|
|
Here are the three possible category lines, each with a comment that
|
|
|
explains what it means:
|
|
|
|
|
|
$(PRE_INSTALL) # Pre-install commands follow.
|
|
|
$(POST_INSTALL) # Post-install commands follow.
|
|
|
$(NORMAL_INSTALL) # Normal commands follow.
|
|
|
|
|
|
If you don't use a category line at the beginning of the 'install'
|
|
|
rule, all the commands are classified as normal until the first category
|
|
|
line. If you don't use any category lines, all the commands are
|
|
|
classified as normal.
|
|
|
|
|
|
These are the category lines for 'uninstall':
|
|
|
|
|
|
$(PRE_UNINSTALL) # Pre-uninstall commands follow.
|
|
|
$(POST_UNINSTALL) # Post-uninstall commands follow.
|
|
|
$(NORMAL_UNINSTALL) # Normal commands follow.
|
|
|
|
|
|
Typically, a pre-uninstall command would be used for deleting entries
|
|
|
from the Info directory.
|
|
|
|
|
|
If the 'install' or 'uninstall' target has any dependencies which act
|
|
|
as subroutines of installation, then you should start _each_
|
|
|
dependency's commands with a category line, and start the main target's
|
|
|
commands with a category line also. This way, you can ensure that each
|
|
|
command is placed in the right category regardless of which of the
|
|
|
dependencies actually run.
|
|
|
|
|
|
Pre-installation and post-installation commands should not run any
|
|
|
programs except for these:
|
|
|
|
|
|
[ basename bash cat chgrp chmod chown cmp cp dd diff echo
|
|
|
egrep expand expr false fgrep find getopt grep gunzip gzip
|
|
|
hostname install install-info kill ldconfig ln ls md5sum
|
|
|
mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee
|
|
|
test touch true uname xargs yes
|
|
|
|
|
|
The reason for distinguishing the commands in this way is for the
|
|
|
sake of making binary packages. Typically a binary package contains all
|
|
|
the executables and other files that need to be installed, and has its
|
|
|
own method of installing them--so it does not need to run the normal
|
|
|
installation commands. But installing the binary package does need to
|
|
|
execute the pre-installation and post-installation commands.
|
|
|
|
|
|
Programs to build binary packages work by extracting the
|
|
|
pre-installation and post-installation commands. Here is one way of
|
|
|
extracting the pre-installation commands (the '-s' option to 'make' is
|
|
|
needed to silence messages about entering subdirectories):
|
|
|
|
|
|
make -s -n install -o all \
|
|
|
PRE_INSTALL=pre-install \
|
|
|
POST_INSTALL=post-install \
|
|
|
NORMAL_INSTALL=normal-install \
|
|
|
| gawk -f pre-install.awk
|
|
|
|
|
|
where the file 'pre-install.awk' could contain this:
|
|
|
|
|
|
$0 ~ /^(normal-install|post-install)[ \t]*$/ {on = 0}
|
|
|
on {print $0}
|
|
|
$0 ~ /^pre-install[ \t]*$/ {on = 1}
|
|
|
|
|
|
|
|
|
File: make.info, Node: Quick Reference, Next: Error Messages, Prev: Makefile Conventions, Up: Top
|
|
|
|
|
|
Appendix A Quick Reference
|
|
|
**************************
|
|
|
|
|
|
This appendix summarizes the directives, text manipulation functions,
|
|
|
and special variables which GNU 'make' understands. *Note Special
|
|
|
Targets::, *note Catalogue of Built-In Rules: Catalogue of Rules, and
|
|
|
*note Summary of Options: Options Summary, for other summaries.
|
|
|
|
|
|
Here is a summary of the directives GNU 'make' recognizes:
|
|
|
|
|
|
'define VARIABLE'
|
|
|
'define VARIABLE ='
|
|
|
'define VARIABLE :='
|
|
|
'define VARIABLE ::='
|
|
|
'define VARIABLE +='
|
|
|
'define VARIABLE ?='
|
|
|
'endef'
|
|
|
Define multi-line variables.
|
|
|
*Note Multi-Line::.
|
|
|
|
|
|
'undefine VARIABLE'
|
|
|
Undefining variables.
|
|
|
*Note Undefine Directive::.
|
|
|
|
|
|
'ifdef VARIABLE'
|
|
|
'ifndef VARIABLE'
|
|
|
'ifeq (A,B)'
|
|
|
'ifeq "A" "B"'
|
|
|
'ifeq 'A' 'B''
|
|
|
'ifneq (A,B)'
|
|
|
'ifneq "A" "B"'
|
|
|
'ifneq 'A' 'B''
|
|
|
'else'
|
|
|
'endif'
|
|
|
Conditionally evaluate part of the makefile.
|
|
|
*Note Conditionals::.
|
|
|
|
|
|
'include FILE'
|
|
|
'-include FILE'
|
|
|
'sinclude FILE'
|
|
|
Include another makefile.
|
|
|
*Note Including Other Makefiles: Include.
|
|
|
|
|
|
'override VARIABLE-ASSIGNMENT'
|
|
|
Define a variable, overriding any previous definition, even one
|
|
|
from the command line.
|
|
|
*Note The 'override' Directive: Override Directive.
|
|
|
|
|
|
'export'
|
|
|
Tell 'make' to export all variables to child processes by default.
|
|
|
*Note Communicating Variables to a Sub-'make': Variables/Recursion.
|
|
|
|
|
|
'export VARIABLE'
|
|
|
'export VARIABLE-ASSIGNMENT'
|
|
|
'unexport VARIABLE'
|
|
|
Tell 'make' whether or not to export a particular variable to child
|
|
|
processes.
|
|
|
*Note Communicating Variables to a Sub-'make': Variables/Recursion.
|
|
|
|
|
|
'private VARIABLE-ASSIGNMENT'
|
|
|
Do not allow this variable assignment to be inherited by
|
|
|
prerequisites.
|
|
|
*Note Suppressing Inheritance::.
|
|
|
|
|
|
'vpath PATTERN PATH'
|
|
|
Specify a search path for files matching a '%' pattern.
|
|
|
*Note The 'vpath' Directive: Selective Search.
|
|
|
|
|
|
'vpath PATTERN'
|
|
|
Remove all search paths previously specified for PATTERN.
|
|
|
|
|
|
'vpath'
|
|
|
Remove all search paths previously specified in any 'vpath'
|
|
|
directive.
|
|
|
|
|
|
Here is a summary of the built-in functions (*note Functions::):
|
|
|
|
|
|
'$(subst FROM,TO,TEXT)'
|
|
|
Replace FROM with TO in TEXT.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(patsubst PATTERN,REPLACEMENT,TEXT)'
|
|
|
Replace words matching PATTERN with REPLACEMENT in TEXT.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(strip STRING)'
|
|
|
Remove excess whitespace characters from STRING.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(findstring FIND,TEXT)'
|
|
|
Locate FIND in TEXT.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(filter PATTERN...,TEXT)'
|
|
|
Select words in TEXT that match one of the PATTERN words.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(filter-out PATTERN...,TEXT)'
|
|
|
Select words in TEXT that _do not_ match any of the PATTERN words.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(sort LIST)'
|
|
|
Sort the words in LIST lexicographically, removing duplicates.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(word N,TEXT)'
|
|
|
Extract the Nth word (one-origin) of TEXT.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(words TEXT)'
|
|
|
Count the number of words in TEXT.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(wordlist S,E,TEXT)'
|
|
|
Returns the list of words in TEXT from S to E.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(firstword NAMES...)'
|
|
|
Extract the first word of NAMES.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(lastword NAMES...)'
|
|
|
Extract the last word of NAMES.
|
|
|
*Note Functions for String Substitution and Analysis: Text
|
|
|
Functions.
|
|
|
|
|
|
'$(dir NAMES...)'
|
|
|
Extract the directory part of each file name.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(notdir NAMES...)'
|
|
|
Extract the non-directory part of each file name.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(suffix NAMES...)'
|
|
|
Extract the suffix (the last '.' and following characters) of each
|
|
|
file name.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(basename NAMES...)'
|
|
|
Extract the base name (name without suffix) of each file name.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(addsuffix SUFFIX,NAMES...)'
|
|
|
Append SUFFIX to each word in NAMES.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(addprefix PREFIX,NAMES...)'
|
|
|
Prepend PREFIX to each word in NAMES.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(join LIST1,LIST2)'
|
|
|
Join two parallel lists of words.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(wildcard PATTERN...)'
|
|
|
Find file names matching a shell file name pattern (_not_ a '%'
|
|
|
pattern).
|
|
|
*Note The Function 'wildcard': Wildcard Function.
|
|
|
|
|
|
'$(realpath NAMES...)'
|
|
|
For each file name in NAMES, expand to an absolute name that does
|
|
|
not contain any '.', '..', nor symlinks.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(abspath NAMES...)'
|
|
|
For each file name in NAMES, expand to an absolute name that does
|
|
|
not contain any '.' or '..' components, but preserves symlinks.
|
|
|
*Note Functions for File Names: File Name Functions.
|
|
|
|
|
|
'$(error TEXT...)'
|
|
|
When this function is evaluated, 'make' generates a fatal error
|
|
|
with the message TEXT.
|
|
|
*Note Functions That Control Make: Make Control Functions.
|
|
|
|
|
|
'$(warning TEXT...)'
|
|
|
When this function is evaluated, 'make' generates a warning with
|
|
|
the message TEXT.
|
|
|
*Note Functions That Control Make: Make Control Functions.
|
|
|
|
|
|
'$(shell COMMAND)'
|
|
|
Execute a shell command and return its output.
|
|
|
*Note The 'shell' Function: Shell Function.
|
|
|
|
|
|
'$(origin VARIABLE)'
|
|
|
Return a string describing how the 'make' variable VARIABLE was
|
|
|
defined.
|
|
|
*Note The 'origin' Function: Origin Function.
|
|
|
|
|
|
'$(flavor VARIABLE)'
|
|
|
Return a string describing the flavor of the 'make' variable
|
|
|
VARIABLE.
|
|
|
*Note The 'flavor' Function: Flavor Function.
|
|
|
|
|
|
'$(foreach VAR,WORDS,TEXT)'
|
|
|
Evaluate TEXT with VAR bound to each word in WORDS, and concatenate
|
|
|
the results.
|
|
|
*Note The 'foreach' Function: Foreach Function.
|
|
|
|
|
|
'$(if CONDITION,THEN-PART[,ELSE-PART])'
|
|
|
Evaluate the condition CONDITION; if it's non-empty substitute the
|
|
|
expansion of the THEN-PART otherwise substitute the expansion of
|
|
|
the ELSE-PART.
|
|
|
*Note Functions for Conditionals: Conditional Functions.
|
|
|
|
|
|
'$(or CONDITION1[,CONDITION2[,CONDITION3...]])'
|
|
|
Evaluate each condition CONDITIONN one at a time; substitute the
|
|
|
first non-empty expansion. If all expansions are empty, substitute
|
|
|
the empty string.
|
|
|
*Note Functions for Conditionals: Conditional Functions.
|
|
|
|
|
|
'$(and CONDITION1[,CONDITION2[,CONDITION3...]])'
|
|
|
Evaluate each condition CONDITIONN one at a time; if any expansion
|
|
|
results in the empty string substitute the empty string. If all
|
|
|
expansions result in a non-empty string, substitute the expansion
|
|
|
of the last CONDITION.
|
|
|
*Note Functions for Conditionals: Conditional Functions.
|
|
|
|
|
|
'$(call VAR,PARAM,...)'
|
|
|
Evaluate the variable VAR replacing any references to '$(1)',
|
|
|
'$(2)' with the first, second, etc. PARAM values.
|
|
|
*Note The 'call' Function: Call Function.
|
|
|
|
|
|
'$(eval TEXT)'
|
|
|
Evaluate TEXT then read the results as makefile commands. Expands
|
|
|
to the empty string.
|
|
|
*Note The 'eval' Function: Eval Function.
|
|
|
|
|
|
'$(file OP FILENAME,TEXT)'
|
|
|
Expand the arguments, then open the file FILENAME using mode OP and
|
|
|
write TEXT to that file.
|
|
|
*Note The 'file' Function: File Function.
|
|
|
|
|
|
'$(value VAR)'
|
|
|
Evaluates to the contents of the variable VAR, with no expansion
|
|
|
performed on it.
|
|
|
*Note The 'value' Function: Value Function.
|
|
|
|
|
|
Here is a summary of the automatic variables. *Note Automatic
|
|
|
Variables::, for full information.
|
|
|
|
|
|
'$@'
|
|
|
The file name of the target.
|
|
|
|
|
|
'$%'
|
|
|
The target member name, when the target is an archive member.
|
|
|
|
|
|
'$<'
|
|
|
The name of the first prerequisite.
|
|
|
|
|
|
'$?'
|
|
|
The names of all the prerequisites that are newer than the target,
|
|
|
with spaces between them. For prerequisites which are archive
|
|
|
members, only the named member is used (*note Archives::).
|
|
|
|
|
|
'$^'
|
|
|
'$+'
|
|
|
The names of all the prerequisites, with spaces between them. For
|
|
|
prerequisites which are archive members, only the named member is
|
|
|
used (*note Archives::). The value of '$^' omits duplicate
|
|
|
prerequisites, while '$+' retains them and preserves their order.
|
|
|
|
|
|
'$*'
|
|
|
The stem with which an implicit rule matches (*note How Patterns
|
|
|
Match: Pattern Match.).
|
|
|
|
|
|
'$(@D)'
|
|
|
'$(@F)'
|
|
|
The directory part and the file-within-directory part of '$@'.
|
|
|
|
|
|
'$(*D)'
|
|
|
'$(*F)'
|
|
|
The directory part and the file-within-directory part of '$*'.
|
|
|
|
|
|
'$(%D)'
|
|
|
'$(%F)'
|
|
|
The directory part and the file-within-directory part of '$%'.
|
|
|
|
|
|
'$(<D)'
|
|
|
'$(<F)'
|
|
|
The directory part and the file-within-directory part of '$<'.
|
|
|
|
|
|
'$(^D)'
|
|
|
'$(^F)'
|
|
|
The directory part and the file-within-directory part of '$^'.
|
|
|
|
|
|
'$(+D)'
|
|
|
'$(+F)'
|
|
|
The directory part and the file-within-directory part of '$+'.
|
|
|
|
|
|
'$(?D)'
|
|
|
'$(?F)'
|
|
|
The directory part and the file-within-directory part of '$?'.
|
|
|
|
|
|
These variables are used specially by GNU 'make':
|
|
|
|
|
|
'MAKEFILES'
|
|
|
|
|
|
Makefiles to be read on every invocation of 'make'.
|
|
|
*Note The Variable 'MAKEFILES': MAKEFILES Variable.
|
|
|
|
|
|
'VPATH'
|
|
|
|
|
|
Directory search path for files not found in the current directory.
|
|
|
*Note 'VPATH' Search Path for All Prerequisites: General Search.
|
|
|
|
|
|
'SHELL'
|
|
|
|
|
|
The name of the system default command interpreter, usually
|
|
|
'/bin/sh'. You can set 'SHELL' in the makefile to change the shell
|
|
|
used to run recipes. *Note Recipe Execution: Execution. The
|
|
|
'SHELL' variable is handled specially when importing from and
|
|
|
exporting to the environment. *Note Choosing the Shell::.
|
|
|
|
|
|
'MAKESHELL'
|
|
|
|
|
|
On MS-DOS only, the name of the command interpreter that is to be
|
|
|
used by 'make'. This value takes precedence over the value of
|
|
|
'SHELL'. *Note MAKESHELL variable: Execution.
|
|
|
|
|
|
'MAKE'
|
|
|
|
|
|
The name with which 'make' was invoked. Using this variable in
|
|
|
recipes has special meaning. *Note How the 'MAKE' Variable Works:
|
|
|
MAKE Variable.
|
|
|
|
|
|
'MAKE_VERSION'
|
|
|
|
|
|
The built-in variable 'MAKE_VERSION' expands to the version number
|
|
|
of the GNU 'make' program.
|
|
|
|
|
|
'MAKE_HOST'
|
|
|
|
|
|
The built-in variable 'MAKE_HOST' expands to a string representing
|
|
|
the host that GNU 'make' was built to run on.
|
|
|
|
|
|
'MAKELEVEL'
|
|
|
|
|
|
The number of levels of recursion (sub-'make's).
|
|
|
*Note Variables/Recursion::.
|
|
|
|
|
|
'MAKEFLAGS'
|
|
|
|
|
|
The flags given to 'make'. You can set this in the environment or
|
|
|
a makefile to set flags.
|
|
|
*Note Communicating Options to a Sub-'make': Options/Recursion.
|
|
|
|
|
|
It is _never_ appropriate to use 'MAKEFLAGS' directly in a recipe
|
|
|
line: its contents may not be quoted correctly for use in the
|
|
|
shell. Always allow recursive 'make''s to obtain these values
|
|
|
through the environment from its parent.
|
|
|
|
|
|
'GNUMAKEFLAGS'
|
|
|
|
|
|
Other flags parsed by 'make'. You can set this in the environment
|
|
|
or a makefile to set 'make' command-line flags. GNU 'make' never
|
|
|
sets this variable itself. This variable is only needed if you'd
|
|
|
like to set GNU 'make'-specific flags in a POSIX-compliant
|
|
|
makefile. This variable will be seen by GNU 'make' and ignored by
|
|
|
other 'make' implementations. It's not needed if you only use GNU
|
|
|
'make'; just use 'MAKEFLAGS' directly. *Note Communicating Options
|
|
|
to a Sub-'make': Options/Recursion.
|
|
|
|
|
|
'MAKECMDGOALS'
|
|
|
|
|
|
The targets given to 'make' on the command line. Setting this
|
|
|
variable has no effect on the operation of 'make'.
|
|
|
*Note Arguments to Specify the Goals: Goals.
|
|
|
|
|
|
'CURDIR'
|
|
|
|
|
|
Set to the absolute pathname of the current working directory
|
|
|
(after all '-C' options are processed, if any). Setting this
|
|
|
variable has no effect on the operation of 'make'.
|
|
|
*Note Recursive Use of 'make': Recursion.
|
|
|
|
|
|
'SUFFIXES'
|
|
|
|
|
|
The default list of suffixes before 'make' reads any makefiles.
|
|
|
|
|
|
'.LIBPATTERNS'
|
|
|
Defines the naming of the libraries 'make' searches for, and their
|
|
|
order.
|
|
|
*Note Directory Search for Link Libraries: Libraries/Search.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Error Messages, Next: Complex Makefile, Prev: Quick Reference, Up: Top
|
|
|
|
|
|
Appendix B Errors Generated by Make
|
|
|
***********************************
|
|
|
|
|
|
Here is a list of the more common errors you might see generated by
|
|
|
'make', and some information about what they mean and how to fix them.
|
|
|
|
|
|
Sometimes 'make' errors are not fatal, especially in the presence of
|
|
|
a '-' prefix on a recipe line, or the '-k' command line option. Errors
|
|
|
that are fatal are prefixed with the string '***'.
|
|
|
|
|
|
Error messages are all either prefixed with the name of the program
|
|
|
(usually 'make'), or, if the error is found in a makefile, the name of
|
|
|
the file and line number containing the problem.
|
|
|
|
|
|
In the table below, these common prefixes are left off.
|
|
|
|
|
|
'[FOO] Error NN'
|
|
|
'[FOO] SIGNAL DESCRIPTION'
|
|
|
These errors are not really 'make' errors at all. They mean that a
|
|
|
program that 'make' invoked as part of a recipe returned a non-0
|
|
|
error code ('Error NN'), which 'make' interprets as failure, or it
|
|
|
exited in some other abnormal fashion (with a signal of some type).
|
|
|
*Note Errors in Recipes: Errors.
|
|
|
|
|
|
If no '***' is attached to the message, then the sub-process failed
|
|
|
but the rule in the makefile was prefixed with the '-' special
|
|
|
character, so 'make' ignored the error.
|
|
|
|
|
|
'missing separator. Stop.'
|
|
|
'missing separator (did you mean TAB instead of 8 spaces?). Stop.'
|
|
|
This means that 'make' could not understand much of anything about
|
|
|
the makefile line it just read. GNU 'make' looks for various
|
|
|
separators (':', '=', recipe prefix characters, etc.) to indicate
|
|
|
what kind of line it's parsing. This message means it couldn't
|
|
|
find a valid one.
|
|
|
|
|
|
One of the most common reasons for this message is that you (or
|
|
|
perhaps your oh-so-helpful editor, as is the case with many
|
|
|
MS-Windows editors) have attempted to indent your recipe lines with
|
|
|
spaces instead of a tab character. In this case, 'make' will use
|
|
|
the second form of the error above. Remember that every line in
|
|
|
the recipe must begin with a tab character (unless you set
|
|
|
'.RECIPEPREFIX'; *note Special Variables::). Eight spaces do not
|
|
|
count. *Note Rule Syntax::.
|
|
|
|
|
|
'recipe commences before first target. Stop.'
|
|
|
'missing rule before recipe. Stop.'
|
|
|
This means the first thing in the makefile seems to be part of a
|
|
|
recipe: it begins with a recipe prefix character and doesn't appear
|
|
|
to be a legal 'make' directive (such as a variable assignment).
|
|
|
Recipes must always be associated with a target.
|
|
|
|
|
|
The second form is generated if the line has a semicolon as the
|
|
|
first non-whitespace character; 'make' interprets this to mean you
|
|
|
left out the "target: prerequisite" section of a rule. *Note Rule
|
|
|
Syntax::.
|
|
|
|
|
|
'No rule to make target `XXX'.'
|
|
|
'No rule to make target `XXX', needed by `YYY'.'
|
|
|
This means that 'make' decided it needed to build a target, but
|
|
|
then couldn't find any instructions in the makefile on how to do
|
|
|
that, either explicit or implicit (including in the default rules
|
|
|
database).
|
|
|
|
|
|
If you want that file to be built, you will need to add a rule to
|
|
|
your makefile describing how that target can be built. Other
|
|
|
possible sources of this problem are typos in the makefile (if that
|
|
|
file name is wrong) or a corrupted source tree (if that file is not
|
|
|
supposed to be built, but rather only a prerequisite).
|
|
|
|
|
|
'No targets specified and no makefile found. Stop.'
|
|
|
'No targets. Stop.'
|
|
|
The former means that you didn't provide any targets to be built on
|
|
|
the command line, and 'make' couldn't find any makefiles to read
|
|
|
in. The latter means that some makefile was found, but it didn't
|
|
|
contain any default goal and none was given on the command line.
|
|
|
GNU 'make' has nothing to do in these situations. *Note Arguments
|
|
|
to Specify the Makefile: Makefile Arguments.
|
|
|
|
|
|
'Makefile `XXX' was not found.'
|
|
|
'Included makefile `XXX' was not found.'
|
|
|
A makefile specified on the command line (first form) or included
|
|
|
(second form) was not found.
|
|
|
|
|
|
'warning: overriding recipe for target `XXX''
|
|
|
'warning: ignoring old recipe for target `XXX''
|
|
|
GNU 'make' allows only one recipe to be specified per target
|
|
|
(except for double-colon rules). If you give a recipe for a target
|
|
|
which already has been defined to have one, this warning is issued
|
|
|
and the second recipe will overwrite the first. *Note Multiple
|
|
|
Rules for One Target: Multiple Rules.
|
|
|
|
|
|
'Circular XXX <- YYY dependency dropped.'
|
|
|
This means that 'make' detected a loop in the dependency graph:
|
|
|
after tracing the prerequisite YYY of target XXX, and its
|
|
|
prerequisites, etc., one of them depended on XXX again.
|
|
|
|
|
|
'Recursive variable `XXX' references itself (eventually). Stop.'
|
|
|
This means you've defined a normal (recursive) 'make' variable XXX
|
|
|
that, when it's expanded, will refer to itself (XXX). This is not
|
|
|
allowed; either use simply-expanded variables (':=' or '::=') or
|
|
|
use the append operator ('+='). *Note How to Use Variables: Using
|
|
|
Variables.
|
|
|
|
|
|
'Unterminated variable reference. Stop.'
|
|
|
This means you forgot to provide the proper closing parenthesis or
|
|
|
brace in your variable or function reference.
|
|
|
|
|
|
'insufficient arguments to function `XXX'. Stop.'
|
|
|
This means you haven't provided the requisite number of arguments
|
|
|
for this function. See the documentation of the function for a
|
|
|
description of its arguments. *Note Functions for Transforming
|
|
|
Text: Functions.
|
|
|
|
|
|
'missing target pattern. Stop.'
|
|
|
'multiple target patterns. Stop.'
|
|
|
'target pattern contains no `%'. Stop.'
|
|
|
'mixed implicit and static pattern rules. Stop.'
|
|
|
These are generated for malformed static pattern rules. The first
|
|
|
means there's no pattern in the target section of the rule; the
|
|
|
second means there are multiple patterns in the target section; the
|
|
|
third means the target doesn't contain a pattern character ('%');
|
|
|
and the fourth means that all three parts of the static pattern
|
|
|
rule contain pattern characters ('%')-only the first two parts
|
|
|
should. If you see these errors and you aren't trying to create a
|
|
|
static pattern rule, check the value of any variables in your
|
|
|
target and prerequisite lists to be sure they do not contain
|
|
|
colons. *Note Syntax of Static Pattern Rules: Static Usage.
|
|
|
|
|
|
'warning: -jN forced in submake: disabling jobserver mode.'
|
|
|
This warning and the next are generated if 'make' detects error
|
|
|
conditions related to parallel processing on systems where
|
|
|
sub-'make's can communicate (*note Communicating Options to a
|
|
|
Sub-'make': Options/Recursion.). This warning is generated if a
|
|
|
recursive invocation of a 'make' process is forced to have '-jN' in
|
|
|
its argument list (where N is greater than one). This could
|
|
|
happen, for example, if you set the 'MAKE' environment variable to
|
|
|
'make -j2'. In this case, the sub-'make' doesn't communicate with
|
|
|
other 'make' processes and will simply pretend it has two jobs of
|
|
|
its own.
|
|
|
|
|
|
'warning: jobserver unavailable: using -j1. Add `+' to parent make rule.'
|
|
|
In order for 'make' processes to communicate, the parent will pass
|
|
|
information to the child. Since this could result in problems if
|
|
|
the child process isn't actually a 'make', the parent will only do
|
|
|
this if it thinks the child is a 'make'. The parent uses the
|
|
|
normal algorithms to determine this (*note How the 'MAKE' Variable
|
|
|
Works: MAKE Variable.). If the makefile is constructed such that
|
|
|
the parent doesn't know the child is a 'make' process, then the
|
|
|
child will receive only part of the information necessary. In this
|
|
|
case, the child will generate this warning message and proceed with
|
|
|
its build in a sequential manner.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Complex Makefile, Next: GNU Free Documentation License, Prev: Error Messages, Up: Top
|
|
|
|
|
|
Appendix C Complex Makefile Example
|
|
|
***********************************
|
|
|
|
|
|
Here is the makefile for the GNU 'tar' program. This is a moderately
|
|
|
complex makefile. The first line uses a '#!' setting to allow the
|
|
|
makefile to be executed directly.
|
|
|
|
|
|
Because it is the first target, the default goal is 'all'. An
|
|
|
interesting feature of this makefile is that 'testpad.h' is a source
|
|
|
file automatically created by the 'testpad' program, itself compiled
|
|
|
from 'testpad.c'.
|
|
|
|
|
|
If you type 'make' or 'make all', then 'make' creates the 'tar'
|
|
|
executable, the 'rmt' daemon that provides remote tape access, and the
|
|
|
'tar.info' Info file.
|
|
|
|
|
|
If you type 'make install', then 'make' not only creates 'tar',
|
|
|
'rmt', and 'tar.info', but also installs them.
|
|
|
|
|
|
If you type 'make clean', then 'make' removes the '.o' files, and the
|
|
|
'tar', 'rmt', 'testpad', 'testpad.h', and 'core' files.
|
|
|
|
|
|
If you type 'make distclean', then 'make' not only removes the same
|
|
|
files as does 'make clean' but also the 'TAGS', 'Makefile', and
|
|
|
'config.status' files. (Although it is not evident, this makefile (and
|
|
|
'config.status') is generated by the user with the 'configure' program,
|
|
|
which is provided in the 'tar' distribution, but is not shown here.)
|
|
|
|
|
|
If you type 'make realclean', then 'make' removes the same files as
|
|
|
does 'make distclean' and also removes the Info files generated from
|
|
|
'tar.texinfo'.
|
|
|
|
|
|
In addition, there are targets 'shar' and 'dist' that create
|
|
|
distribution kits.
|
|
|
|
|
|
#!/usr/bin/make -f
|
|
|
# Generated automatically from Makefile.in by configure.
|
|
|
# Un*x Makefile for GNU tar program.
|
|
|
# Copyright (C) 1991 Free Software Foundation, Inc.
|
|
|
|
|
|
# This program is free software; you can redistribute
|
|
|
# it and/or modify it under the terms of the GNU
|
|
|
# General Public License ...
|
|
|
...
|
|
|
...
|
|
|
|
|
|
SHELL = /bin/sh
|
|
|
|
|
|
#### Start of system configuration section. ####
|
|
|
|
|
|
srcdir = .
|
|
|
|
|
|
# If you use gcc, you should either run the
|
|
|
# fixincludes script that comes with it or else use
|
|
|
# gcc with the -traditional option. Otherwise ioctl
|
|
|
# calls will be compiled incorrectly on some systems.
|
|
|
CC = gcc -O
|
|
|
YACC = bison -y
|
|
|
INSTALL = /usr/local/bin/install -c
|
|
|
INSTALLDATA = /usr/local/bin/install -c -m 644
|
|
|
|
|
|
# Things you might add to DEFS:
|
|
|
# -DSTDC_HEADERS If you have ANSI C headers and
|
|
|
# libraries.
|
|
|
# -DPOSIX If you have POSIX.1 headers and
|
|
|
# libraries.
|
|
|
# -DBSD42 If you have sys/dir.h (unless
|
|
|
# you use -DPOSIX), sys/file.h,
|
|
|
# and st_blocks in `struct stat'.
|
|
|
# -DUSG If you have System V/ANSI C
|
|
|
# string and memory functions
|
|
|
# and headers, sys/sysmacros.h,
|
|
|
# fcntl.h, getcwd, no valloc,
|
|
|
# and ndir.h (unless
|
|
|
# you use -DDIRENT).
|
|
|
# -DNO_MEMORY_H If USG or STDC_HEADERS but do not
|
|
|
# include memory.h.
|
|
|
# -DDIRENT If USG and you have dirent.h
|
|
|
# instead of ndir.h.
|
|
|
# -DSIGTYPE=int If your signal handlers
|
|
|
# return int, not void.
|
|
|
# -DNO_MTIO If you lack sys/mtio.h
|
|
|
# (magtape ioctls).
|
|
|
# -DNO_REMOTE If you do not have a remote shell
|
|
|
# or rexec.
|
|
|
# -DUSE_REXEC To use rexec for remote tape
|
|
|
# operations instead of
|
|
|
# forking rsh or remsh.
|
|
|
# -DVPRINTF_MISSING If you lack vprintf function
|
|
|
# (but have _doprnt).
|
|
|
# -DDOPRNT_MISSING If you lack _doprnt function.
|
|
|
# Also need to define
|
|
|
# -DVPRINTF_MISSING.
|
|
|
# -DFTIME_MISSING If you lack ftime system call.
|
|
|
# -DSTRSTR_MISSING If you lack strstr function.
|
|
|
# -DVALLOC_MISSING If you lack valloc function.
|
|
|
# -DMKDIR_MISSING If you lack mkdir and
|
|
|
# rmdir system calls.
|
|
|
# -DRENAME_MISSING If you lack rename system call.
|
|
|
# -DFTRUNCATE_MISSING If you lack ftruncate
|
|
|
# system call.
|
|
|
# -DV7 On Version 7 Unix (not
|
|
|
# tested in a long time).
|
|
|
# -DEMUL_OPEN3 If you lack a 3-argument version
|
|
|
# of open, and want to emulate it
|
|
|
# with system calls you do have.
|
|
|
# -DNO_OPEN3 If you lack the 3-argument open
|
|
|
# and want to disable the tar -k
|
|
|
# option instead of emulating open.
|
|
|
# -DXENIX If you have sys/inode.h
|
|
|
# and need it 94 to be included.
|
|
|
|
|
|
DEFS = -DSIGTYPE=int -DDIRENT -DSTRSTR_MISSING \
|
|
|
-DVPRINTF_MISSING -DBSD42
|
|
|
# Set this to rtapelib.o unless you defined NO_REMOTE,
|
|
|
# in which case make it empty.
|
|
|
RTAPELIB = rtapelib.o
|
|
|
LIBS =
|
|
|
DEF_AR_FILE = /dev/rmt8
|
|
|
DEFBLOCKING = 20
|
|
|
|
|
|
CDEBUG = -g
|
|
|
CFLAGS = $(CDEBUG) -I. -I$(srcdir) $(DEFS) \
|
|
|
-DDEF_AR_FILE=\"$(DEF_AR_FILE)\" \
|
|
|
-DDEFBLOCKING=$(DEFBLOCKING)
|
|
|
LDFLAGS = -g
|
|
|
|
|
|
prefix = /usr/local
|
|
|
# Prefix for each installed program,
|
|
|
# normally empty or `g'.
|
|
|
binprefix =
|
|
|
|
|
|
# The directory to install tar in.
|
|
|
bindir = $(prefix)/bin
|
|
|
|
|
|
# The directory to install the info files in.
|
|
|
infodir = $(prefix)/info
|
|
|
|
|
|
#### End of system configuration section. ####
|
|
|
|
|
|
SRCS_C = tar.c create.c extract.c buffer.c \
|
|
|
getoldopt.c update.c gnu.c mangle.c \
|
|
|
version.c list.c names.c diffarch.c \
|
|
|
port.c wildmat.c getopt.c getopt1.c \
|
|
|
regex.c
|
|
|
SRCS_Y = getdate.y
|
|
|
SRCS = $(SRCS_C) $(SRCS_Y)
|
|
|
OBJS = $(SRCS_C:.c=.o) $(SRCS_Y:.y=.o) $(RTAPELIB)
|
|
|
AUX = README COPYING ChangeLog Makefile.in \
|
|
|
makefile.pc configure configure.in \
|
|
|
tar.texinfo tar.info* texinfo.tex \
|
|
|
tar.h port.h open3.h getopt.h regex.h \
|
|
|
rmt.h rmt.c rtapelib.c alloca.c \
|
|
|
msd_dir.h msd_dir.c tcexparg.c \
|
|
|
level-0 level-1 backup-specs testpad.c
|
|
|
|
|
|
.PHONY: all
|
|
|
all: tar rmt tar.info
|
|
|
|
|
|
tar: $(OBJS)
|
|
|
$(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
|
|
|
|
|
|
rmt: rmt.c
|
|
|
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ rmt.c
|
|
|
|
|
|
tar.info: tar.texinfo
|
|
|
makeinfo tar.texinfo
|
|
|
|
|
|
.PHONY: install
|
|
|
install: all
|
|
|
$(INSTALL) tar $(bindir)/$(binprefix)tar
|
|
|
-test ! -f rmt || $(INSTALL) rmt /etc/rmt
|
|
|
$(INSTALLDATA) $(srcdir)/tar.info* $(infodir)
|
|
|
|
|
|
$(OBJS): tar.h port.h testpad.h
|
|
|
regex.o buffer.o tar.o: regex.h
|
|
|
# getdate.y has 8 shift/reduce conflicts.
|
|
|
|
|
|
testpad.h: testpad
|
|
|
./testpad
|
|
|
|
|
|
testpad: testpad.o
|
|
|
$(CC) -o $@ testpad.o
|
|
|
|
|
|
TAGS: $(SRCS)
|
|
|
etags $(SRCS)
|
|
|
|
|
|
.PHONY: clean
|
|
|
clean:
|
|
|
rm -f *.o tar rmt testpad testpad.h core
|
|
|
|
|
|
.PHONY: distclean
|
|
|
distclean: clean
|
|
|
rm -f TAGS Makefile config.status
|
|
|
|
|
|
.PHONY: realclean
|
|
|
realclean: distclean
|
|
|
rm -f tar.info*
|
|
|
|
|
|
.PHONY: shar
|
|
|
shar: $(SRCS) $(AUX)
|
|
|
shar $(SRCS) $(AUX) | compress \
|
|
|
> tar-`sed -e '/version_string/!d' \
|
|
|
-e 's/[^0-9.]*\([0-9.]*\).*/\1/' \
|
|
|
-e q
|
|
|
version.c`.shar.Z
|
|
|
|
|
|
.PHONY: dist
|
|
|
dist: $(SRCS) $(AUX)
|
|
|
echo tar-`sed \
|
|
|
-e '/version_string/!d' \
|
|
|
-e 's/[^0-9.]*\([0-9.]*\).*/\1/' \
|
|
|
-e q
|
|
|
version.c` > .fname
|
|
|
-rm -rf `cat .fname`
|
|
|
mkdir `cat .fname`
|
|
|
ln $(SRCS) $(AUX) `cat .fname`
|
|
|
tar chZf `cat .fname`.tar.Z `cat .fname`
|
|
|
-rm -rf `cat .fname` .fname
|
|
|
|
|
|
tar.zoo: $(SRCS) $(AUX)
|
|
|
-rm -rf tmp.dir
|
|
|
-mkdir tmp.dir
|
|
|
-rm tar.zoo
|
|
|
for X in $(SRCS) $(AUX) ; do \
|
|
|
echo $$X ; \
|
|
|
sed 's/$$/^M/' $$X \
|
|
|
> tmp.dir/$$X ; done
|
|
|
cd tmp.dir ; zoo aM ../tar.zoo *
|
|
|
-rm -rf tmp.dir
|
|
|
|
|
|
|
|
|
File: make.info, Node: GNU Free Documentation License, Next: Concept Index, Prev: Complex Makefile, Up: Top
|
|
|
|
|
|
C.1 GNU Free Documentation License
|
|
|
==================================
|
|
|
|
|
|
Version 1.3, 3 November 2008
|
|
|
|
|
|
Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
|
|
|
<https://fsf.org/>
|
|
|
|
|
|
Everyone is permitted to copy and distribute verbatim copies
|
|
|
of this license document, but changing it is not allowed.
|
|
|
|
|
|
0. PREAMBLE
|
|
|
|
|
|
The purpose of this License is to make a manual, textbook, or other
|
|
|
functional and useful document "free" in the sense of freedom: to
|
|
|
assure everyone the effective freedom to copy and redistribute it,
|
|
|
with or without modifying it, either commercially or
|
|
|
noncommercially. Secondarily, this License preserves for the
|
|
|
author and publisher a way to get credit for their work, while not
|
|
|
being considered responsible for modifications made by others.
|
|
|
|
|
|
This License is a kind of "copyleft", which means that derivative
|
|
|
works of the document must themselves be free in the same sense.
|
|
|
It complements the GNU General Public License, which is a copyleft
|
|
|
license designed for free software.
|
|
|
|
|
|
We have designed this License in order to use it for manuals for
|
|
|
free software, because free software needs free documentation: a
|
|
|
free program should come with manuals providing the same freedoms
|
|
|
that the software does. But this License is not limited to
|
|
|
software manuals; it can be used for any textual work, regardless
|
|
|
of subject matter or whether it is published as a printed book. We
|
|
|
recommend this License principally for works whose purpose is
|
|
|
instruction or reference.
|
|
|
|
|
|
1. APPLICABILITY AND DEFINITIONS
|
|
|
|
|
|
This License applies to any manual or other work, in any medium,
|
|
|
that contains a notice placed by the copyright holder saying it can
|
|
|
be distributed under the terms of this License. Such a notice
|
|
|
grants a world-wide, royalty-free license, unlimited in duration,
|
|
|
to use that work under the conditions stated herein. The
|
|
|
"Document", below, refers to any such manual or work. Any member
|
|
|
of the public is a licensee, and is addressed as "you". You accept
|
|
|
the license if you copy, modify or distribute the work in a way
|
|
|
requiring permission under copyright law.
|
|
|
|
|
|
A "Modified Version" of the Document means any work containing the
|
|
|
Document or a portion of it, either copied verbatim, or with
|
|
|
modifications and/or translated into another language.
|
|
|
|
|
|
A "Secondary Section" is a named appendix or a front-matter section
|
|
|
of the Document that deals exclusively with the relationship of the
|
|
|
publishers or authors of the Document to the Document's overall
|
|
|
subject (or to related matters) and contains nothing that could
|
|
|
fall directly within that overall subject. (Thus, if the Document
|
|
|
is in part a textbook of mathematics, a Secondary Section may not
|
|
|
explain any mathematics.) The relationship could be a matter of
|
|
|
historical connection with the subject or with related matters, or
|
|
|
of legal, commercial, philosophical, ethical or political position
|
|
|
regarding them.
|
|
|
|
|
|
The "Invariant Sections" are certain Secondary Sections whose
|
|
|
titles are designated, as being those of Invariant Sections, in the
|
|
|
notice that says that the Document is released under this License.
|
|
|
If a section does not fit the above definition of Secondary then it
|
|
|
is not allowed to be designated as Invariant. The Document may
|
|
|
contain zero Invariant Sections. If the Document does not identify
|
|
|
any Invariant Sections then there are none.
|
|
|
|
|
|
The "Cover Texts" are certain short passages of text that are
|
|
|
listed, as Front-Cover Texts or Back-Cover Texts, in the notice
|
|
|
that says that the Document is released under this License. A
|
|
|
Front-Cover Text may be at most 5 words, and a Back-Cover Text may
|
|
|
be at most 25 words.
|
|
|
|
|
|
A "Transparent" copy of the Document means a machine-readable copy,
|
|
|
represented in a format whose specification is available to the
|
|
|
general public, that is suitable for revising the document
|
|
|
straightforwardly with generic text editors or (for images composed
|
|
|
of pixels) generic paint programs or (for drawings) some widely
|
|
|
available drawing editor, and that is suitable for input to text
|
|
|
formatters or for automatic translation to a variety of formats
|
|
|
suitable for input to text formatters. A copy made in an otherwise
|
|
|
Transparent file format whose markup, or absence of markup, has
|
|
|
been arranged to thwart or discourage subsequent modification by
|
|
|
readers is not Transparent. An image format is not Transparent if
|
|
|
used for any substantial amount of text. A copy that is not
|
|
|
"Transparent" is called "Opaque".
|
|
|
|
|
|
Examples of suitable formats for Transparent copies include plain
|
|
|
ASCII without markup, Texinfo input format, LaTeX input format,
|
|
|
SGML or XML using a publicly available DTD, and standard-conforming
|
|
|
simple HTML, PostScript or PDF designed for human modification.
|
|
|
Examples of transparent image formats include PNG, XCF and JPG.
|
|
|
Opaque formats include proprietary formats that can be read and
|
|
|
edited only by proprietary word processors, SGML or XML for which
|
|
|
the DTD and/or processing tools are not generally available, and
|
|
|
the machine-generated HTML, PostScript or PDF produced by some word
|
|
|
processors for output purposes only.
|
|
|
|
|
|
The "Title Page" means, for a printed book, the title page itself,
|
|
|
plus such following pages as are needed to hold, legibly, the
|
|
|
material this License requires to appear in the title page. For
|
|
|
works in formats which do not have any title page as such, "Title
|
|
|
Page" means the text near the most prominent appearance of the
|
|
|
work's title, preceding the beginning of the body of the text.
|
|
|
|
|
|
The "publisher" means any person or entity that distributes copies
|
|
|
of the Document to the public.
|
|
|
|
|
|
A section "Entitled XYZ" means a named subunit of the Document
|
|
|
whose title either is precisely XYZ or contains XYZ in parentheses
|
|
|
following text that translates XYZ in another language. (Here XYZ
|
|
|
stands for a specific section name mentioned below, such as
|
|
|
"Acknowledgements", "Dedications", "Endorsements", or "History".)
|
|
|
To "Preserve the Title" of such a section when you modify the
|
|
|
Document means that it remains a section "Entitled XYZ" according
|
|
|
to this definition.
|
|
|
|
|
|
The Document may include Warranty Disclaimers next to the notice
|
|
|
which states that this License applies to the Document. These
|
|
|
Warranty Disclaimers are considered to be included by reference in
|
|
|
this License, but only as regards disclaiming warranties: any other
|
|
|
implication that these Warranty Disclaimers may have is void and
|
|
|
has no effect on the meaning of this License.
|
|
|
|
|
|
2. VERBATIM COPYING
|
|
|
|
|
|
You may copy and distribute the Document in any medium, either
|
|
|
commercially or noncommercially, provided that this License, the
|
|
|
copyright notices, and the license notice saying this License
|
|
|
applies to the Document are reproduced in all copies, and that you
|
|
|
add no other conditions whatsoever to those of this License. You
|
|
|
may not use technical measures to obstruct or control the reading
|
|
|
or further copying of the copies you make or distribute. However,
|
|
|
you may accept compensation in exchange for copies. If you
|
|
|
distribute a large enough number of copies you must also follow the
|
|
|
conditions in section 3.
|
|
|
|
|
|
You may also lend copies, under the same conditions stated above,
|
|
|
and you may publicly display copies.
|
|
|
|
|
|
3. COPYING IN QUANTITY
|
|
|
|
|
|
If you publish printed copies (or copies in media that commonly
|
|
|
have printed covers) of the Document, numbering more than 100, and
|
|
|
the Document's license notice requires Cover Texts, you must
|
|
|
enclose the copies in covers that carry, clearly and legibly, all
|
|
|
these Cover Texts: Front-Cover Texts on the front cover, and
|
|
|
Back-Cover Texts on the back cover. Both covers must also clearly
|
|
|
and legibly identify you as the publisher of these copies. The
|
|
|
front cover must present the full title with all words of the title
|
|
|
equally prominent and visible. You may add other material on the
|
|
|
covers in addition. Copying with changes limited to the covers, as
|
|
|
long as they preserve the title of the Document and satisfy these
|
|
|
conditions, can be treated as verbatim copying in other respects.
|
|
|
|
|
|
If the required texts for either cover are too voluminous to fit
|
|
|
legibly, you should put the first ones listed (as many as fit
|
|
|
reasonably) on the actual cover, and continue the rest onto
|
|
|
adjacent pages.
|
|
|
|
|
|
If you publish or distribute Opaque copies of the Document
|
|
|
numbering more than 100, you must either include a machine-readable
|
|
|
Transparent copy along with each Opaque copy, or state in or with
|
|
|
each Opaque copy a computer-network location from which the general
|
|
|
network-using public has access to download using public-standard
|
|
|
network protocols a complete Transparent copy of the Document, free
|
|
|
of added material. If you use the latter option, you must take
|
|
|
reasonably prudent steps, when you begin distribution of Opaque
|
|
|
copies in quantity, to ensure that this Transparent copy will
|
|
|
remain thus accessible at the stated location until at least one
|
|
|
year after the last time you distribute an Opaque copy (directly or
|
|
|
through your agents or retailers) of that edition to the public.
|
|
|
|
|
|
It is requested, but not required, that you contact the authors of
|
|
|
the Document well before redistributing any large number of copies,
|
|
|
to give them a chance to provide you with an updated version of the
|
|
|
Document.
|
|
|
|
|
|
4. MODIFICATIONS
|
|
|
|
|
|
You may copy and distribute a Modified Version of the Document
|
|
|
under the conditions of sections 2 and 3 above, provided that you
|
|
|
release the Modified Version under precisely this License, with the
|
|
|
Modified Version filling the role of the Document, thus licensing
|
|
|
distribution and modification of the Modified Version to whoever
|
|
|
possesses a copy of it. In addition, you must do these things in
|
|
|
the Modified Version:
|
|
|
|
|
|
A. Use in the Title Page (and on the covers, if any) a title
|
|
|
distinct from that of the Document, and from those of previous
|
|
|
versions (which should, if there were any, be listed in the
|
|
|
History section of the Document). You may use the same title
|
|
|
as a previous version if the original publisher of that
|
|
|
version gives permission.
|
|
|
|
|
|
B. List on the Title Page, as authors, one or more persons or
|
|
|
entities responsible for authorship of the modifications in
|
|
|
the Modified Version, together with at least five of the
|
|
|
principal authors of the Document (all of its principal
|
|
|
authors, if it has fewer than five), unless they release you
|
|
|
from this requirement.
|
|
|
|
|
|
C. State on the Title page the name of the publisher of the
|
|
|
Modified Version, as the publisher.
|
|
|
|
|
|
D. Preserve all the copyright notices of the Document.
|
|
|
|
|
|
E. Add an appropriate copyright notice for your modifications
|
|
|
adjacent to the other copyright notices.
|
|
|
|
|
|
F. Include, immediately after the copyright notices, a license
|
|
|
notice giving the public permission to use the Modified
|
|
|
Version under the terms of this License, in the form shown in
|
|
|
the Addendum below.
|
|
|
|
|
|
G. Preserve in that license notice the full lists of Invariant
|
|
|
Sections and required Cover Texts given in the Document's
|
|
|
license notice.
|
|
|
|
|
|
H. Include an unaltered copy of this License.
|
|
|
|
|
|
I. Preserve the section Entitled "History", Preserve its Title,
|
|
|
and add to it an item stating at least the title, year, new
|
|
|
authors, and publisher of the Modified Version as given on the
|
|
|
Title Page. If there is no section Entitled "History" in the
|
|
|
Document, create one stating the title, year, authors, and
|
|
|
publisher of the Document as given on its Title Page, then add
|
|
|
an item describing the Modified Version as stated in the
|
|
|
previous sentence.
|
|
|
|
|
|
J. Preserve the network location, if any, given in the Document
|
|
|
for public access to a Transparent copy of the Document, and
|
|
|
likewise the network locations given in the Document for
|
|
|
previous versions it was based on. These may be placed in the
|
|
|
"History" section. You may omit a network location for a work
|
|
|
that was published at least four years before the Document
|
|
|
itself, or if the original publisher of the version it refers
|
|
|
to gives permission.
|
|
|
|
|
|
K. For any section Entitled "Acknowledgements" or "Dedications",
|
|
|
Preserve the Title of the section, and preserve in the section
|
|
|
all the substance and tone of each of the contributor
|
|
|
acknowledgements and/or dedications given therein.
|
|
|
|
|
|
L. Preserve all the Invariant Sections of the Document, unaltered
|
|
|
in their text and in their titles. Section numbers or the
|
|
|
equivalent are not considered part of the section titles.
|
|
|
|
|
|
M. Delete any section Entitled "Endorsements". Such a section
|
|
|
may not be included in the Modified Version.
|
|
|
|
|
|
N. Do not retitle any existing section to be Entitled
|
|
|
"Endorsements" or to conflict in title with any Invariant
|
|
|
Section.
|
|
|
|
|
|
O. Preserve any Warranty Disclaimers.
|
|
|
|
|
|
If the Modified Version includes new front-matter sections or
|
|
|
appendices that qualify as Secondary Sections and contain no
|
|
|
material copied from the Document, you may at your option designate
|
|
|
some or all of these sections as invariant. To do this, add their
|
|
|
titles to the list of Invariant Sections in the Modified Version's
|
|
|
license notice. These titles must be distinct from any other
|
|
|
section titles.
|
|
|
|
|
|
You may add a section Entitled "Endorsements", provided it contains
|
|
|
nothing but endorsements of your Modified Version by various
|
|
|
parties--for example, statements of peer review or that the text
|
|
|
has been approved by an organization as the authoritative
|
|
|
definition of a standard.
|
|
|
|
|
|
You may add a passage of up to five words as a Front-Cover Text,
|
|
|
and a passage of up to 25 words as a Back-Cover Text, to the end of
|
|
|
the list of Cover Texts in the Modified Version. Only one passage
|
|
|
of Front-Cover Text and one of Back-Cover Text may be added by (or
|
|
|
through arrangements made by) any one entity. If the Document
|
|
|
already includes a cover text for the same cover, previously added
|
|
|
by you or by arrangement made by the same entity you are acting on
|
|
|
behalf of, you may not add another; but you may replace the old
|
|
|
one, on explicit permission from the previous publisher that added
|
|
|
the old one.
|
|
|
|
|
|
The author(s) and publisher(s) of the Document do not by this
|
|
|
License give permission to use their names for publicity for or to
|
|
|
assert or imply endorsement of any Modified Version.
|
|
|
|
|
|
5. COMBINING DOCUMENTS
|
|
|
|
|
|
You may combine the Document with other documents released under
|
|
|
this License, under the terms defined in section 4 above for
|
|
|
modified versions, provided that you include in the combination all
|
|
|
of the Invariant Sections of all of the original documents,
|
|
|
unmodified, and list them all as Invariant Sections of your
|
|
|
combined work in its license notice, and that you preserve all
|
|
|
their Warranty Disclaimers.
|
|
|
|
|
|
The combined work need only contain one copy of this License, and
|
|
|
multiple identical Invariant Sections may be replaced with a single
|
|
|
copy. If there are multiple Invariant Sections with the same name
|
|
|
but different contents, make the title of each such section unique
|
|
|
by adding at the end of it, in parentheses, the name of the
|
|
|
original author or publisher of that section if known, or else a
|
|
|
unique number. Make the same adjustment to the section titles in
|
|
|
the list of Invariant Sections in the license notice of the
|
|
|
combined work.
|
|
|
|
|
|
In the combination, you must combine any sections Entitled
|
|
|
"History" in the various original documents, forming one section
|
|
|
Entitled "History"; likewise combine any sections Entitled
|
|
|
"Acknowledgements", and any sections Entitled "Dedications". You
|
|
|
must delete all sections Entitled "Endorsements."
|
|
|
|
|
|
6. COLLECTIONS OF DOCUMENTS
|
|
|
|
|
|
You may make a collection consisting of the Document and other
|
|
|
documents released under this License, and replace the individual
|
|
|
copies of this License in the various documents with a single copy
|
|
|
that is included in the collection, provided that you follow the
|
|
|
rules of this License for verbatim copying of each of the documents
|
|
|
in all other respects.
|
|
|
|
|
|
You may extract a single document from such a collection, and
|
|
|
distribute it individually under this License, provided you insert
|
|
|
a copy of this License into the extracted document, and follow this
|
|
|
License in all other respects regarding verbatim copying of that
|
|
|
document.
|
|
|
|
|
|
7. AGGREGATION WITH INDEPENDENT WORKS
|
|
|
|
|
|
A compilation of the Document or its derivatives with other
|
|
|
separate and independent documents or works, in or on a volume of a
|
|
|
storage or distribution medium, is called an "aggregate" if the
|
|
|
copyright resulting from the compilation is not used to limit the
|
|
|
legal rights of the compilation's users beyond what the individual
|
|
|
works permit. When the Document is included in an aggregate, this
|
|
|
License does not apply to the other works in the aggregate which
|
|
|
are not themselves derivative works of the Document.
|
|
|
|
|
|
If the Cover Text requirement of section 3 is applicable to these
|
|
|
copies of the Document, then if the Document is less than one half
|
|
|
of the entire aggregate, the Document's Cover Texts may be placed
|
|
|
on covers that bracket the Document within the aggregate, or the
|
|
|
electronic equivalent of covers if the Document is in electronic
|
|
|
form. Otherwise they must appear on printed covers that bracket
|
|
|
the whole aggregate.
|
|
|
|
|
|
8. TRANSLATION
|
|
|
|
|
|
Translation is considered a kind of modification, so you may
|
|
|
distribute translations of the Document under the terms of section
|
|
|
4. Replacing Invariant Sections with translations requires special
|
|
|
permission from their copyright holders, but you may include
|
|
|
translations of some or all Invariant Sections in addition to the
|
|
|
original versions of these Invariant Sections. You may include a
|
|
|
translation of this License, and all the license notices in the
|
|
|
Document, and any Warranty Disclaimers, provided that you also
|
|
|
include the original English version of this License and the
|
|
|
original versions of those notices and disclaimers. In case of a
|
|
|
disagreement between the translation and the original version of
|
|
|
this License or a notice or disclaimer, the original version will
|
|
|
prevail.
|
|
|
|
|
|
If a section in the Document is Entitled "Acknowledgements",
|
|
|
"Dedications", or "History", the requirement (section 4) to
|
|
|
Preserve its Title (section 1) will typically require changing the
|
|
|
actual title.
|
|
|
|
|
|
9. TERMINATION
|
|
|
|
|
|
You may not copy, modify, sublicense, or distribute the Document
|
|
|
except as expressly provided under this License. Any attempt
|
|
|
otherwise to copy, modify, sublicense, or distribute it is void,
|
|
|
and will automatically terminate your rights under this License.
|
|
|
|
|
|
However, if you cease all violation of this License, then your
|
|
|
license from a particular copyright holder is reinstated (a)
|
|
|
provisionally, unless and until the copyright holder explicitly and
|
|
|
finally terminates your license, and (b) permanently, if the
|
|
|
copyright holder fails to notify you of the violation by some
|
|
|
reasonable means prior to 60 days after the cessation.
|
|
|
|
|
|
Moreover, your license from a particular copyright holder is
|
|
|
reinstated permanently if the copyright holder notifies you of the
|
|
|
violation by some reasonable means, this is the first time you have
|
|
|
received notice of violation of this License (for any work) from
|
|
|
that copyright holder, and you cure the violation prior to 30 days
|
|
|
after your receipt of the notice.
|
|
|
|
|
|
Termination of your rights under this section does not terminate
|
|
|
the licenses of parties who have received copies or rights from you
|
|
|
under this License. If your rights have been terminated and not
|
|
|
permanently reinstated, receipt of a copy of some or all of the
|
|
|
same material does not give you any rights to use it.
|
|
|
|
|
|
10. FUTURE REVISIONS OF THIS LICENSE
|
|
|
|
|
|
The Free Software Foundation may publish new, revised versions of
|
|
|
the GNU Free Documentation License from time to time. Such new
|
|
|
versions will be similar in spirit to the present version, but may
|
|
|
differ in detail to address new problems or concerns. See
|
|
|
<https://www.gnu.org/copyleft/>.
|
|
|
|
|
|
Each version of the License is given a distinguishing version
|
|
|
number. If the Document specifies that a particular numbered
|
|
|
version of this License "or any later version" applies to it, you
|
|
|
have the option of following the terms and conditions either of
|
|
|
that specified version or of any later version that has been
|
|
|
published (not as a draft) by the Free Software Foundation. If the
|
|
|
Document does not specify a version number of this License, you may
|
|
|
choose any version ever published (not as a draft) by the Free
|
|
|
Software Foundation. If the Document specifies that a proxy can
|
|
|
decide which future versions of this License can be used, that
|
|
|
proxy's public statement of acceptance of a version permanently
|
|
|
authorizes you to choose that version for the Document.
|
|
|
|
|
|
11. RELICENSING
|
|
|
|
|
|
"Massive Multiauthor Collaboration Site" (or "MMC Site") means any
|
|
|
World Wide Web server that publishes copyrightable works and also
|
|
|
provides prominent facilities for anybody to edit those works. A
|
|
|
public wiki that anybody can edit is an example of such a server.
|
|
|
A "Massive Multiauthor Collaboration" (or "MMC") contained in the
|
|
|
site means any set of copyrightable works thus published on the MMC
|
|
|
site.
|
|
|
|
|
|
"CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
|
|
|
license published by Creative Commons Corporation, a not-for-profit
|
|
|
corporation with a principal place of business in San Francisco,
|
|
|
California, as well as future copyleft versions of that license
|
|
|
published by that same organization.
|
|
|
|
|
|
"Incorporate" means to publish or republish a Document, in whole or
|
|
|
in part, as part of another Document.
|
|
|
|
|
|
An MMC is "eligible for relicensing" if it is licensed under this
|
|
|
License, and if all works that were first published under this
|
|
|
License somewhere other than this MMC, and subsequently
|
|
|
incorporated in whole or in part into the MMC, (1) had no cover
|
|
|
texts or invariant sections, and (2) were thus incorporated prior
|
|
|
to November 1, 2008.
|
|
|
|
|
|
The operator of an MMC Site may republish an MMC contained in the
|
|
|
site under CC-BY-SA on the same site at any time before August 1,
|
|
|
2009, provided the MMC is eligible for relicensing.
|
|
|
|
|
|
ADDENDUM: How to use this License for your documents
|
|
|
====================================================
|
|
|
|
|
|
To use this License in a document you have written, include a copy of
|
|
|
the License in the document and put the following copyright and license
|
|
|
notices just after the title page:
|
|
|
|
|
|
Copyright (C) YEAR YOUR NAME.
|
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
|
under the terms of the GNU Free Documentation License, Version 1.3
|
|
|
or any later version published by the Free Software Foundation;
|
|
|
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
|
|
|
Texts. A copy of the license is included in the section entitled ``GNU
|
|
|
Free Documentation License''.
|
|
|
|
|
|
If you have Invariant Sections, Front-Cover Texts and Back-Cover
|
|
|
Texts, replace the "with...Texts." line with this:
|
|
|
|
|
|
with the Invariant Sections being LIST THEIR TITLES, with
|
|
|
the Front-Cover Texts being LIST, and with the Back-Cover Texts
|
|
|
being LIST.
|
|
|
|
|
|
If you have Invariant Sections without Cover Texts, or some other
|
|
|
combination of the three, merge those two alternatives to suit the
|
|
|
situation.
|
|
|
|
|
|
If your document contains nontrivial examples of program code, we
|
|
|
recommend releasing these examples in parallel under your choice of free
|
|
|
software license, such as the GNU General Public License, to permit
|
|
|
their use in free software.
|
|
|
|
|
|
|
|
|
File: make.info, Node: Concept Index, Next: Name Index, Prev: GNU Free Documentation License, Up: Top
|
|
|
|
|
|
Index of Concepts
|
|
|
*****************
|
|
|
|
|
|
[index ]
|
|
|
* Menu:
|
|
|
|
|
|
* !=: Setting. (line 6)
|
|
|
* !=, expansion: Reading Makefiles. (line 33)
|
|
|
* '#' (comments), in makefile: Makefile Contents. (line 41)
|
|
|
* '#' (comments), in recipes: Recipe Syntax. (line 29)
|
|
|
* '#include': Automatic Prerequisites.
|
|
|
(line 16)
|
|
|
* '$', in function call: Syntax of Functions. (line 6)
|
|
|
* '$', in rules: Rule Syntax. (line 33)
|
|
|
* '$', in variable name: Computed Names. (line 6)
|
|
|
* '$', in variable reference: Reference. (line 6)
|
|
|
* '%', in pattern rules: Pattern Intro. (line 9)
|
|
|
* '%', quoting in 'patsubst': Text Functions. (line 26)
|
|
|
* '%', quoting in static pattern: Static Usage. (line 37)
|
|
|
* '%', quoting in 'vpath': Selective Search. (line 39)
|
|
|
* '%', quoting with '\' (backslash): Selective Search. (line 39)
|
|
|
* '%', quoting with '\' (backslash) <1>: Static Usage. (line 37)
|
|
|
* '%', quoting with '\' (backslash) <2>: Text Functions. (line 26)
|
|
|
* '*' (wildcard character): Wildcards. (line 6)
|
|
|
* +, and 'define': Canned Recipes. (line 49)
|
|
|
* +, and recipe execution: Instead of Execution.
|
|
|
(line 67)
|
|
|
* +, and recipes: MAKE Variable. (line 18)
|
|
|
* +=: Appending. (line 6)
|
|
|
* +=, expansion: Reading Makefiles. (line 33)
|
|
|
* +=, expansion <1>: Reading Makefiles. (line 33)
|
|
|
* ,v (RCS file extension): Catalogue of Rules. (line 163)
|
|
|
* '-' (in recipes): Errors. (line 19)
|
|
|
* -, and 'define': Canned Recipes. (line 49)
|
|
|
* '--always-make': Options Summary. (line 15)
|
|
|
* '--assume-new': Instead of Execution.
|
|
|
(line 41)
|
|
|
* '--assume-new' <1>: Options Summary. (line 284)
|
|
|
* '--assume-new', and recursion: Options/Recursion. (line 22)
|
|
|
* '--assume-old': Avoiding Compilation.
|
|
|
(line 6)
|
|
|
* '--assume-old' <1>: Options Summary. (line 163)
|
|
|
* '--assume-old', and recursion: Options/Recursion. (line 22)
|
|
|
* '--check-symlink-times': Options Summary. (line 144)
|
|
|
* '--debug': Options Summary. (line 43)
|
|
|
* '--directory': Recursion. (line 20)
|
|
|
* '--directory' <1>: Options Summary. (line 26)
|
|
|
* '--directory', and '--print-directory': -w Option. (line 20)
|
|
|
* '--directory', and recursion: Options/Recursion. (line 22)
|
|
|
* '--dry-run': Echoing. (line 18)
|
|
|
* '--dry-run' <1>: Instead of Execution.
|
|
|
(line 14)
|
|
|
* '--dry-run' <2>: Options Summary. (line 154)
|
|
|
* '--environment-overrides': Options Summary. (line 85)
|
|
|
* '--eval': Options Summary. (line 89)
|
|
|
* '--file': Makefile Names. (line 23)
|
|
|
* '--file' <1>: Makefile Arguments. (line 6)
|
|
|
* '--file' <2>: Options Summary. (line 97)
|
|
|
* '--file', and recursion: Options/Recursion. (line 22)
|
|
|
* '--help': Options Summary. (line 103)
|
|
|
* '--ignore-errors': Errors. (line 30)
|
|
|
* '--ignore-errors' <1>: Options Summary. (line 108)
|
|
|
* '--include-dir': Include. (line 53)
|
|
|
* '--include-dir' <1>: Options Summary. (line 113)
|
|
|
* '--jobs': Parallel. (line 6)
|
|
|
* '--jobs' <1>: Options Summary. (line 120)
|
|
|
* '--jobs', and recursion: Options/Recursion. (line 25)
|
|
|
* '--just-print': Echoing. (line 18)
|
|
|
* '--just-print' <1>: Instead of Execution.
|
|
|
(line 14)
|
|
|
* '--just-print' <2>: Options Summary. (line 153)
|
|
|
* '--keep-going': Errors. (line 47)
|
|
|
* '--keep-going' <1>: Testing. (line 16)
|
|
|
* '--keep-going' <2>: Options Summary. (line 129)
|
|
|
* '--load-average': Parallel. (line 35)
|
|
|
* '--load-average' <1>: Options Summary. (line 136)
|
|
|
* '--makefile': Makefile Names. (line 23)
|
|
|
* '--makefile' <1>: Makefile Arguments. (line 6)
|
|
|
* '--makefile' <2>: Options Summary. (line 98)
|
|
|
* '--max-load': Parallel. (line 35)
|
|
|
* '--max-load' <1>: Options Summary. (line 137)
|
|
|
* '--new-file': Instead of Execution.
|
|
|
(line 41)
|
|
|
* '--new-file' <1>: Options Summary. (line 283)
|
|
|
* '--new-file', and recursion: Options/Recursion. (line 22)
|
|
|
* '--no-builtin-rules': Options Summary. (line 209)
|
|
|
* '--no-builtin-variables': Options Summary. (line 222)
|
|
|
* '--no-keep-going': Options Summary. (line 238)
|
|
|
* '--no-print-directory': -w Option. (line 20)
|
|
|
* '--no-print-directory' <1>: Options Summary. (line 275)
|
|
|
* '--old-file': Avoiding Compilation.
|
|
|
(line 6)
|
|
|
* '--old-file' <1>: Options Summary. (line 162)
|
|
|
* '--old-file', and recursion: Options/Recursion. (line 22)
|
|
|
* '--output-sync': Parallel Output. (line 11)
|
|
|
* '--output-sync' <1>: Options Summary. (line 171)
|
|
|
* '--print-data-base': Options Summary. (line 187)
|
|
|
* '--print-directory': Options Summary. (line 267)
|
|
|
* '--print-directory', and '--directory': -w Option. (line 20)
|
|
|
* '--print-directory', and recursion: -w Option. (line 20)
|
|
|
* '--print-directory', disabling: -w Option. (line 20)
|
|
|
* '--question': Instead of Execution.
|
|
|
(line 32)
|
|
|
* '--question' <1>: Options Summary. (line 201)
|
|
|
* '--quiet': Echoing. (line 24)
|
|
|
* '--quiet' <1>: Options Summary. (line 232)
|
|
|
* '--recon': Echoing. (line 18)
|
|
|
* '--recon' <1>: Instead of Execution.
|
|
|
(line 14)
|
|
|
* '--recon' <2>: Options Summary. (line 155)
|
|
|
* '--silent': Echoing. (line 24)
|
|
|
* '--silent' <1>: Options Summary. (line 231)
|
|
|
* '--stop': Options Summary. (line 239)
|
|
|
* '--touch': Instead of Execution.
|
|
|
(line 24)
|
|
|
* '--touch' <1>: Options Summary. (line 247)
|
|
|
* '--touch', and recursion: MAKE Variable. (line 35)
|
|
|
* '--trace': Options Summary. (line 254)
|
|
|
* '--version': Options Summary. (line 262)
|
|
|
* '--warn-undefined-variables': Options Summary. (line 292)
|
|
|
* '--what-if': Instead of Execution.
|
|
|
(line 41)
|
|
|
* '--what-if' <1>: Options Summary. (line 282)
|
|
|
* '-b': Options Summary. (line 9)
|
|
|
* '-B': Options Summary. (line 14)
|
|
|
* '-C': Recursion. (line 20)
|
|
|
* '-C' <1>: Options Summary. (line 25)
|
|
|
* '-C', and '-w': -w Option. (line 20)
|
|
|
* '-C', and recursion: Options/Recursion. (line 22)
|
|
|
* '-d': Options Summary. (line 33)
|
|
|
* '-e': Options Summary. (line 84)
|
|
|
* '-e' (shell flag): Automatic Prerequisites.
|
|
|
(line 65)
|
|
|
* '-f': Makefile Names. (line 23)
|
|
|
* '-f' <1>: Makefile Arguments. (line 6)
|
|
|
* '-f' <2>: Options Summary. (line 96)
|
|
|
* '-f', and recursion: Options/Recursion. (line 22)
|
|
|
* '-h': Options Summary. (line 102)
|
|
|
* '-I': Include. (line 53)
|
|
|
* '-i': Errors. (line 30)
|
|
|
* '-i' <1>: Options Summary. (line 107)
|
|
|
* '-I' <1>: Options Summary. (line 112)
|
|
|
* '-j': Parallel. (line 6)
|
|
|
* '-j' <1>: Options Summary. (line 119)
|
|
|
* '-j', and archive update: Archive Pitfalls. (line 6)
|
|
|
* '-j', and recursion: Options/Recursion. (line 25)
|
|
|
* '-k': Errors. (line 47)
|
|
|
* '-k' <1>: Testing. (line 16)
|
|
|
* '-k' <2>: Options Summary. (line 128)
|
|
|
* '-l': Options Summary. (line 135)
|
|
|
* '-L': Options Summary. (line 143)
|
|
|
* '-l' (library search): Libraries/Search. (line 6)
|
|
|
* '-l' (load average): Parallel. (line 35)
|
|
|
* '-m': Options Summary. (line 10)
|
|
|
* '-M' (to compiler): Automatic Prerequisites.
|
|
|
(line 18)
|
|
|
* '-MM' (to GNU compiler): Automatic Prerequisites.
|
|
|
(line 67)
|
|
|
* '-n': Echoing. (line 18)
|
|
|
* '-n' <1>: Instead of Execution.
|
|
|
(line 14)
|
|
|
* '-n' <2>: Options Summary. (line 152)
|
|
|
* '-O': Parallel Output. (line 11)
|
|
|
* '-o': Avoiding Compilation.
|
|
|
(line 6)
|
|
|
* '-o' <1>: Options Summary. (line 161)
|
|
|
* '-O' <1>: Options Summary. (line 170)
|
|
|
* '-o', and recursion: Options/Recursion. (line 22)
|
|
|
* '-p': Options Summary. (line 186)
|
|
|
* '-q': Instead of Execution.
|
|
|
(line 32)
|
|
|
* '-q' <1>: Options Summary. (line 200)
|
|
|
* '-r': Options Summary. (line 208)
|
|
|
* '-R': Options Summary. (line 221)
|
|
|
* '-s': Echoing. (line 24)
|
|
|
* '-s' <1>: Options Summary. (line 230)
|
|
|
* '-S': Options Summary. (line 237)
|
|
|
* '-t': Instead of Execution.
|
|
|
(line 24)
|
|
|
* '-t' <1>: Options Summary. (line 246)
|
|
|
* '-t', and recursion: MAKE Variable. (line 35)
|
|
|
* '-v': Options Summary. (line 261)
|
|
|
* '-W': Instead of Execution.
|
|
|
(line 41)
|
|
|
* '-w': Options Summary. (line 266)
|
|
|
* '-W' <1>: Options Summary. (line 281)
|
|
|
* '-w', and '-C': -w Option. (line 20)
|
|
|
* '-W', and recursion: Options/Recursion. (line 22)
|
|
|
* '-w', and recursion: -w Option. (line 20)
|
|
|
* '-w', disabling: -w Option. (line 20)
|
|
|
* '.a' (archives): Archive Suffix Rules.
|
|
|
(line 6)
|
|
|
* .c: Catalogue of Rules. (line 35)
|
|
|
* .C: Catalogue of Rules. (line 39)
|
|
|
* .cc: Catalogue of Rules. (line 39)
|
|
|
* .ch: Catalogue of Rules. (line 149)
|
|
|
* .cpp: Catalogue of Rules. (line 39)
|
|
|
* '.d': Automatic Prerequisites.
|
|
|
(line 80)
|
|
|
* .def: Catalogue of Rules. (line 71)
|
|
|
* .dvi: Catalogue of Rules. (line 149)
|
|
|
* .f: Catalogue of Rules. (line 49)
|
|
|
* .F: Catalogue of Rules. (line 49)
|
|
|
* .info: Catalogue of Rules. (line 156)
|
|
|
* .l: Catalogue of Rules. (line 121)
|
|
|
* '.LIBPATTERNS', and link libraries: Libraries/Search. (line 6)
|
|
|
* .ln: Catalogue of Rules. (line 143)
|
|
|
* .mod: Catalogue of Rules. (line 71)
|
|
|
* .o: Catalogue of Rules. (line 35)
|
|
|
* .o <1>: Catalogue of Rules. (line 83)
|
|
|
* '.ONESHELL', use of: One Shell. (line 6)
|
|
|
* .p: Catalogue of Rules. (line 45)
|
|
|
* '.PRECIOUS' intermediate files: Chained Rules. (line 56)
|
|
|
* .r: Catalogue of Rules. (line 49)
|
|
|
* .s: Catalogue of Rules. (line 76)
|
|
|
* .S: Catalogue of Rules. (line 79)
|
|
|
* .sh: Catalogue of Rules. (line 178)
|
|
|
* '.SHELLFLAGS', value of: Choosing the Shell. (line 6)
|
|
|
* .sym: Catalogue of Rules. (line 71)
|
|
|
* .tex: Catalogue of Rules. (line 149)
|
|
|
* .texi: Catalogue of Rules. (line 156)
|
|
|
* .texinfo: Catalogue of Rules. (line 156)
|
|
|
* .txinfo: Catalogue of Rules. (line 156)
|
|
|
* .w: Catalogue of Rules. (line 149)
|
|
|
* .web: Catalogue of Rules. (line 149)
|
|
|
* .y: Catalogue of Rules. (line 117)
|
|
|
* '::' rules (double-colon): Double-Colon. (line 6)
|
|
|
* ::=: Flavors. (line 56)
|
|
|
* ::= <1>: Setting. (line 6)
|
|
|
* :=: Flavors. (line 56)
|
|
|
* := <1>: Setting. (line 6)
|
|
|
* =: Flavors. (line 10)
|
|
|
* = <1>: Setting. (line 6)
|
|
|
* =, expansion: Reading Makefiles. (line 33)
|
|
|
* '?' (wildcard character): Wildcards. (line 6)
|
|
|
* ?=: Flavors. (line 135)
|
|
|
* ?= <1>: Setting. (line 6)
|
|
|
* ?=, expansion: Reading Makefiles. (line 33)
|
|
|
* '@' (in recipes): Echoing. (line 6)
|
|
|
* @, and 'define': Canned Recipes. (line 49)
|
|
|
* '[...]' (wildcard characters): Wildcards. (line 6)
|
|
|
* '\' (backslash), for continuation lines: Simple Makefile. (line 41)
|
|
|
* '\' (backslash), in recipes: Splitting Recipe Lines.
|
|
|
(line 6)
|
|
|
* '\' (backslash), to quote '%': Selective Search. (line 39)
|
|
|
* '\' (backslash), to quote '%' <1>: Static Usage. (line 37)
|
|
|
* '\' (backslash), to quote '%' <2>: Text Functions. (line 26)
|
|
|
* '__.SYMDEF': Archive Symbols. (line 6)
|
|
|
* '~' (tilde): Wildcards. (line 11)
|
|
|
* abspath: File Name Functions. (line 120)
|
|
|
* algorithm for directory search: Search Algorithm. (line 6)
|
|
|
* 'all' (standard target): Goals. (line 73)
|
|
|
* appending to variables: Appending. (line 6)
|
|
|
* ar: Implicit Variables. (line 40)
|
|
|
* archive: Archives. (line 6)
|
|
|
* archive member targets: Archive Members. (line 6)
|
|
|
* archive symbol directory updating: Archive Symbols. (line 6)
|
|
|
* archive, and '-j': Archive Pitfalls. (line 6)
|
|
|
* archive, and parallel execution: Archive Pitfalls. (line 6)
|
|
|
* archive, suffix rule for: Archive Suffix Rules.
|
|
|
(line 6)
|
|
|
* Arg list too long: Options/Recursion. (line 58)
|
|
|
* arguments of functions: Syntax of Functions. (line 6)
|
|
|
* as: Catalogue of Rules. (line 76)
|
|
|
* as <1>: Implicit Variables. (line 43)
|
|
|
* assembly, rule to compile: Catalogue of Rules. (line 76)
|
|
|
* automatic generation of prerequisites: Include. (line 51)
|
|
|
* automatic generation of prerequisites <1>: Automatic Prerequisites.
|
|
|
(line 6)
|
|
|
* automatic variables: Automatic Variables. (line 6)
|
|
|
* automatic variables in prerequisites: Automatic Variables. (line 17)
|
|
|
* backquotes: Shell Function. (line 6)
|
|
|
* backslash ('\'), for continuation lines: Simple Makefile. (line 41)
|
|
|
* backslash ('\'), in recipes: Splitting Recipe Lines.
|
|
|
(line 6)
|
|
|
* backslash ('\'), to quote '%': Selective Search. (line 39)
|
|
|
* backslash ('\'), to quote '%' <1>: Static Usage. (line 37)
|
|
|
* backslash ('\'), to quote '%' <2>: Text Functions. (line 26)
|
|
|
* backslash ('\'), to quote newlines: Splitting Lines. (line 6)
|
|
|
* backslashes in pathnames and wildcard expansion: Wildcard Pitfall.
|
|
|
(line 31)
|
|
|
* basename: File Name Functions. (line 56)
|
|
|
* binary packages: Install Command Categories.
|
|
|
(line 80)
|
|
|
* broken pipe: Parallel Input. (line 11)
|
|
|
* bugs, reporting: Bugs. (line 6)
|
|
|
* built-in special targets: Special Targets. (line 6)
|
|
|
* C++, rule to compile: Catalogue of Rules. (line 39)
|
|
|
* C, rule to compile: Catalogue of Rules. (line 35)
|
|
|
* canned recipes: Canned Recipes. (line 6)
|
|
|
* cc: Catalogue of Rules. (line 35)
|
|
|
* cc <1>: Implicit Variables. (line 46)
|
|
|
* 'cd' (shell command): Execution. (line 12)
|
|
|
* 'cd' (shell command) <1>: MAKE Variable. (line 16)
|
|
|
* chains of rules: Chained Rules. (line 6)
|
|
|
* 'check' (standard target): Goals. (line 115)
|
|
|
* 'clean' (standard target): Goals. (line 76)
|
|
|
* 'clean' target: Simple Makefile. (line 85)
|
|
|
* 'clean' target <1>: Cleanup. (line 11)
|
|
|
* cleaning up: Cleanup. (line 6)
|
|
|
* 'clobber' (standard target): Goals. (line 87)
|
|
|
* co: Catalogue of Rules. (line 163)
|
|
|
* co <1>: Implicit Variables. (line 66)
|
|
|
* combining rules by prerequisite: Combine By Prerequisite.
|
|
|
(line 6)
|
|
|
* command expansion: Shell Function. (line 6)
|
|
|
* command line variable definitions, and recursion: Options/Recursion.
|
|
|
(line 17)
|
|
|
* command line variables: Overriding. (line 6)
|
|
|
* commands, sequences of: Canned Recipes. (line 6)
|
|
|
* comments, in makefile: Makefile Contents. (line 41)
|
|
|
* comments, in recipes: Recipe Syntax. (line 29)
|
|
|
* compatibility: Features. (line 6)
|
|
|
* compatibility in exporting: Variables/Recursion. (line 104)
|
|
|
* compilation, testing: Testing. (line 6)
|
|
|
* computed variable name: Computed Names. (line 6)
|
|
|
* conditional expansion: Conditional Functions.
|
|
|
(line 6)
|
|
|
* conditional variable assignment: Flavors. (line 135)
|
|
|
* conditionals: Conditionals. (line 6)
|
|
|
* continuation lines: Simple Makefile. (line 41)
|
|
|
* controlling make: Make Control Functions.
|
|
|
(line 6)
|
|
|
* conventions for makefiles: Makefile Conventions.
|
|
|
(line 6)
|
|
|
* convert guile types: Guile Types. (line 6)
|
|
|
* ctangle: Catalogue of Rules. (line 149)
|
|
|
* ctangle <1>: Implicit Variables. (line 103)
|
|
|
* cweave: Catalogue of Rules. (line 149)
|
|
|
* cweave <1>: Implicit Variables. (line 97)
|
|
|
* data base of 'make' rules: Options Summary. (line 187)
|
|
|
* deducing recipes (implicit rules): make Deduces. (line 6)
|
|
|
* default directories for included makefiles: Include. (line 53)
|
|
|
* default goal: How Make Works. (line 11)
|
|
|
* default goal <1>: Rules. (line 11)
|
|
|
* default makefile name: Makefile Names. (line 6)
|
|
|
* default rules, last-resort: Last Resort. (line 6)
|
|
|
* define, expansion: Reading Makefiles. (line 33)
|
|
|
* defining variables verbatim: Multi-Line. (line 6)
|
|
|
* deletion of target files: Errors. (line 64)
|
|
|
* deletion of target files <1>: Interrupts. (line 6)
|
|
|
* directive: Makefile Contents. (line 28)
|
|
|
* directories, creating installation: Directory Variables. (line 20)
|
|
|
* directories, printing them: -w Option. (line 6)
|
|
|
* directories, updating archive symbol: Archive Symbols. (line 6)
|
|
|
* directory part: File Name Functions. (line 16)
|
|
|
* directory search ('VPATH'): Directory Search. (line 6)
|
|
|
* directory search ('VPATH'), and implicit rules: Implicit/Search.
|
|
|
(line 6)
|
|
|
* directory search ('VPATH'), and link libraries: Libraries/Search.
|
|
|
(line 6)
|
|
|
* directory search ('VPATH'), and recipes: Recipes/Search. (line 6)
|
|
|
* directory search algorithm: Search Algorithm. (line 6)
|
|
|
* directory search, traditional (GPATH): Search Algorithm. (line 42)
|
|
|
* 'dist' (standard target): Goals. (line 107)
|
|
|
* 'distclean' (standard target): Goals. (line 85)
|
|
|
* dollar sign ('$'), in function call: Syntax of Functions. (line 6)
|
|
|
* dollar sign ('$'), in rules: Rule Syntax. (line 33)
|
|
|
* dollar sign ('$'), in variable name: Computed Names. (line 6)
|
|
|
* dollar sign ('$'), in variable reference: Reference. (line 6)
|
|
|
* DOS, choosing a shell in: Choosing the Shell. (line 38)
|
|
|
* double-colon rules: Double-Colon. (line 6)
|
|
|
* duplicate words, removing: Text Functions. (line 155)
|
|
|
* E2BIG: Options/Recursion. (line 58)
|
|
|
* echoing of recipes: Echoing. (line 6)
|
|
|
* editor: Introduction. (line 22)
|
|
|
* Emacs ('M-x compile'): Errors. (line 62)
|
|
|
* empty recipes: Empty Recipes. (line 6)
|
|
|
* empty targets: Empty Targets. (line 6)
|
|
|
* environment: Environment. (line 6)
|
|
|
* environment, and recursion: Variables/Recursion. (line 6)
|
|
|
* environment, 'SHELL' in: Choosing the Shell. (line 12)
|
|
|
* error, stopping on: Make Control Functions.
|
|
|
(line 11)
|
|
|
* errors (in recipes): Errors. (line 6)
|
|
|
* errors with wildcards: Wildcard Pitfall. (line 6)
|
|
|
* evaluating makefile syntax: Eval Function. (line 6)
|
|
|
* example of loaded objects: Loaded Object Example.
|
|
|
(line 6)
|
|
|
* example using Guile: Guile Example. (line 6)
|
|
|
* execution, in parallel: Parallel. (line 6)
|
|
|
* execution, instead of: Instead of Execution.
|
|
|
(line 6)
|
|
|
* execution, of recipes: Execution. (line 6)
|
|
|
* exit status (errors): Errors. (line 6)
|
|
|
* exit status of make: Running. (line 18)
|
|
|
* expansion, secondary: Secondary Expansion. (line 6)
|
|
|
* explicit rule, definition of: Makefile Contents. (line 10)
|
|
|
* explicit rule, expansion: Reading Makefiles. (line 92)
|
|
|
* explicit rules, secondary expansion of: Secondary Expansion.
|
|
|
(line 104)
|
|
|
* exporting variables: Variables/Recursion. (line 6)
|
|
|
* extensions, Guile: Guile Integration. (line 6)
|
|
|
* extensions, load directive: load Directive. (line 6)
|
|
|
* extensions, loading: Loading Objects. (line 6)
|
|
|
* f77: Catalogue of Rules. (line 49)
|
|
|
* f77 <1>: Implicit Variables. (line 57)
|
|
|
* FDL, GNU Free Documentation License: GNU Free Documentation License.
|
|
|
(line 6)
|
|
|
* features of GNU 'make': Features. (line 6)
|
|
|
* features, missing: Missing. (line 6)
|
|
|
* file name functions: File Name Functions. (line 6)
|
|
|
* file name of makefile: Makefile Names. (line 6)
|
|
|
* file name of makefile, how to specify: Makefile Names. (line 31)
|
|
|
* file name prefix, adding: File Name Functions. (line 78)
|
|
|
* file name suffix: File Name Functions. (line 42)
|
|
|
* file name suffix, adding: File Name Functions. (line 67)
|
|
|
* file name with wildcards: Wildcards. (line 6)
|
|
|
* file name, abspath of: File Name Functions. (line 120)
|
|
|
* file name, basename of: File Name Functions. (line 56)
|
|
|
* file name, directory part: File Name Functions. (line 16)
|
|
|
* file name, nondirectory part: File Name Functions. (line 26)
|
|
|
* file name, realpath of: File Name Functions. (line 113)
|
|
|
* file, reading from: File Function. (line 6)
|
|
|
* file, writing to: File Function. (line 6)
|
|
|
* files, assuming new: Instead of Execution.
|
|
|
(line 41)
|
|
|
* files, assuming old: Avoiding Compilation.
|
|
|
(line 6)
|
|
|
* files, avoiding recompilation of: Avoiding Compilation.
|
|
|
(line 6)
|
|
|
* files, intermediate: Chained Rules. (line 16)
|
|
|
* filtering out words: Text Functions. (line 133)
|
|
|
* filtering words: Text Functions. (line 115)
|
|
|
* finding strings: Text Functions. (line 104)
|
|
|
* flags: Options Summary. (line 6)
|
|
|
* flags for compilers: Implicit Variables. (line 6)
|
|
|
* flavor of variable: Flavor Function. (line 6)
|
|
|
* flavors of variables: Flavors. (line 6)
|
|
|
* 'FORCE': Force Targets. (line 6)
|
|
|
* force targets: Force Targets. (line 6)
|
|
|
* Fortran, rule to compile: Catalogue of Rules. (line 49)
|
|
|
* functions: Functions. (line 6)
|
|
|
* functions, for controlling make: Make Control Functions.
|
|
|
(line 6)
|
|
|
* functions, for file names: File Name Functions. (line 6)
|
|
|
* functions, for text: Text Functions. (line 6)
|
|
|
* functions, syntax of: Syntax of Functions. (line 6)
|
|
|
* functions, user defined: Call Function. (line 6)
|
|
|
* g++: Catalogue of Rules. (line 39)
|
|
|
* g++ <1>: Implicit Variables. (line 49)
|
|
|
* gcc: Catalogue of Rules. (line 35)
|
|
|
* generating prerequisites automatically: Include. (line 51)
|
|
|
* generating prerequisites automatically <1>: Automatic Prerequisites.
|
|
|
(line 6)
|
|
|
* get: Catalogue of Rules. (line 172)
|
|
|
* get <1>: Implicit Variables. (line 69)
|
|
|
* globbing (wildcards): Wildcards. (line 6)
|
|
|
* goal: How Make Works. (line 11)
|
|
|
* goal, default: How Make Works. (line 11)
|
|
|
* goal, default <1>: Rules. (line 11)
|
|
|
* goal, how to specify: Goals. (line 6)
|
|
|
* Guile: Guile Function. (line 6)
|
|
|
* Guile <1>: Guile Integration. (line 6)
|
|
|
* Guile example: Guile Example. (line 6)
|
|
|
* guile, conversion of types: Guile Types. (line 6)
|
|
|
* home directory: Wildcards. (line 11)
|
|
|
* IEEE Standard 1003.2: Overview. (line 13)
|
|
|
* ifdef, expansion: Reading Makefiles. (line 82)
|
|
|
* ifeq, expansion: Reading Makefiles. (line 82)
|
|
|
* ifndef, expansion: Reading Makefiles. (line 82)
|
|
|
* ifneq, expansion: Reading Makefiles. (line 82)
|
|
|
* implicit rule: Implicit Rules. (line 6)
|
|
|
* implicit rule, and directory search: Implicit/Search. (line 6)
|
|
|
* implicit rule, and 'VPATH': Implicit/Search. (line 6)
|
|
|
* implicit rule, definition of: Makefile Contents. (line 16)
|
|
|
* implicit rule, expansion: Reading Makefiles. (line 92)
|
|
|
* implicit rule, how to use: Using Implicit. (line 6)
|
|
|
* implicit rule, introduction to: make Deduces. (line 6)
|
|
|
* implicit rule, predefined: Catalogue of Rules. (line 6)
|
|
|
* implicit rule, search algorithm: Implicit Rule Search.
|
|
|
(line 6)
|
|
|
* implicit rules, secondary expansion of: Secondary Expansion.
|
|
|
(line 144)
|
|
|
* included makefiles, default directories: Include. (line 53)
|
|
|
* including ('MAKEFILES' variable): MAKEFILES Variable. (line 6)
|
|
|
* including ('MAKEFILE_LIST' variable): Special Variables. (line 8)
|
|
|
* including other makefiles: Include. (line 6)
|
|
|
* incompatibilities: Missing. (line 6)
|
|
|
* Info, rule to format: Catalogue of Rules. (line 156)
|
|
|
* inheritance, suppressing: Suppressing Inheritance.
|
|
|
(line 6)
|
|
|
* input during parallel execution: Parallel Input. (line 6)
|
|
|
* 'install' (standard target): Goals. (line 93)
|
|
|
* installation directories, creating: Directory Variables. (line 20)
|
|
|
* installations, staged: DESTDIR. (line 6)
|
|
|
* interface for loaded objects: Loaded Object API. (line 6)
|
|
|
* intermediate files: Chained Rules. (line 16)
|
|
|
* intermediate files, preserving: Chained Rules. (line 46)
|
|
|
* intermediate targets, explicit: Special Targets. (line 48)
|
|
|
* interrupt: Interrupts. (line 6)
|
|
|
* job slots: Parallel. (line 6)
|
|
|
* job slots, and recursion: Options/Recursion. (line 25)
|
|
|
* job slots, sharing: Job Slots. (line 6)
|
|
|
* jobs, limiting based on load: Parallel. (line 35)
|
|
|
* jobserver: Job Slots. (line 16)
|
|
|
* jobserver on POSIX: POSIX Jobserver. (line 6)
|
|
|
* jobserver on Windows: Windows Jobserver. (line 6)
|
|
|
* joining lists of words: File Name Functions. (line 89)
|
|
|
* killing (interruption): Interrupts. (line 6)
|
|
|
* last-resort default rules: Last Resort. (line 6)
|
|
|
* ld: Catalogue of Rules. (line 83)
|
|
|
* lex: Catalogue of Rules. (line 121)
|
|
|
* lex <1>: Implicit Variables. (line 73)
|
|
|
* Lex, rule to run: Catalogue of Rules. (line 121)
|
|
|
* libraries for linking, directory search: Libraries/Search. (line 6)
|
|
|
* library archive, suffix rule for: Archive Suffix Rules.
|
|
|
(line 6)
|
|
|
* limiting jobs based on load: Parallel. (line 35)
|
|
|
* link libraries, and directory search: Libraries/Search. (line 6)
|
|
|
* link libraries, patterns matching: Libraries/Search. (line 6)
|
|
|
* linking, predefined rule for: Catalogue of Rules. (line 83)
|
|
|
* lint: Catalogue of Rules. (line 143)
|
|
|
* lint <1>: Implicit Variables. (line 80)
|
|
|
* 'lint', rule to run: Catalogue of Rules. (line 143)
|
|
|
* list of all prerequisites: Automatic Variables. (line 61)
|
|
|
* list of changed prerequisites: Automatic Variables. (line 51)
|
|
|
* load average: Parallel. (line 35)
|
|
|
* load directive: load Directive. (line 6)
|
|
|
* loaded object API: Loaded Object API. (line 6)
|
|
|
* loaded object example: Loaded Object Example.
|
|
|
(line 6)
|
|
|
* loaded object licensing: Loaded Object API. (line 31)
|
|
|
* loaded objects: Loading Objects. (line 6)
|
|
|
* loaded objects, remaking of: Remaking Loaded Objects.
|
|
|
(line 6)
|
|
|
* long lines, splitting: Splitting Lines. (line 6)
|
|
|
* loops in variable expansion: Flavors. (line 44)
|
|
|
* 'lpr' (shell command): Wildcard Examples. (line 21)
|
|
|
* 'lpr' (shell command) <1>: Empty Targets. (line 25)
|
|
|
* m2c: Catalogue of Rules. (line 71)
|
|
|
* m2c <1>: Implicit Variables. (line 60)
|
|
|
* macro: Using Variables. (line 10)
|
|
|
* 'make depend': Automatic Prerequisites.
|
|
|
(line 37)
|
|
|
* make extensions: Extending make. (line 6)
|
|
|
* make integration: Integrating make. (line 6)
|
|
|
* make interface to guile: Guile Interface. (line 6)
|
|
|
* make procedures in guile: Guile Interface. (line 6)
|
|
|
* makefile: Introduction. (line 7)
|
|
|
* makefile name: Makefile Names. (line 6)
|
|
|
* makefile name, how to specify: Makefile Names. (line 31)
|
|
|
* makefile rule parts: Rule Introduction. (line 6)
|
|
|
* makefile syntax, evaluating: Eval Function. (line 6)
|
|
|
* makefile, and 'MAKEFILES' variable: MAKEFILES Variable. (line 6)
|
|
|
* makefile, conventions for: Makefile Conventions.
|
|
|
(line 6)
|
|
|
* makefile, how 'make' processes: How Make Works. (line 6)
|
|
|
* makefile, how to write: Makefiles. (line 6)
|
|
|
* makefile, including: Include. (line 6)
|
|
|
* makefile, overriding: Overriding Makefiles.
|
|
|
(line 6)
|
|
|
* makefile, parsing: Reading Makefiles. (line 6)
|
|
|
* makefile, remaking of: Remaking Makefiles. (line 6)
|
|
|
* makefile, simple: Simple Makefile. (line 6)
|
|
|
* makefiles, and 'MAKEFILE_LIST' variable: Special Variables. (line 8)
|
|
|
* makefiles, and special variables: Special Variables. (line 6)
|
|
|
* makeinfo: Catalogue of Rules. (line 156)
|
|
|
* makeinfo <1>: Implicit Variables. (line 84)
|
|
|
* match-anything rule: Match-Anything Rules.
|
|
|
(line 6)
|
|
|
* match-anything rule, used to override: Overriding Makefiles.
|
|
|
(line 12)
|
|
|
* missing features: Missing. (line 6)
|
|
|
* mistakes with wildcards: Wildcard Pitfall. (line 6)
|
|
|
* modified variable reference: Substitution Refs. (line 6)
|
|
|
* Modula-2, rule to compile: Catalogue of Rules. (line 71)
|
|
|
* 'mostlyclean' (standard target): Goals. (line 79)
|
|
|
* multi-line variable definition: Multi-Line. (line 6)
|
|
|
* multiple rules for one target: Multiple Rules. (line 6)
|
|
|
* multiple rules for one target ('::'): Double-Colon. (line 6)
|
|
|
* multiple targets: Multiple Targets. (line 6)
|
|
|
* multiple targets, in pattern rule: Pattern Intro. (line 53)
|
|
|
* name of makefile: Makefile Names. (line 6)
|
|
|
* name of makefile, how to specify: Makefile Names. (line 31)
|
|
|
* nested variable reference: Computed Names. (line 6)
|
|
|
* newline, quoting, in makefile: Simple Makefile. (line 41)
|
|
|
* newline, quoting, in recipes: Splitting Recipe Lines.
|
|
|
(line 6)
|
|
|
* nondirectory part: File Name Functions. (line 26)
|
|
|
* normal prerequisites: Prerequisite Types. (line 6)
|
|
|
* 'obj': Variables Simplify. (line 20)
|
|
|
* 'OBJ': Variables Simplify. (line 20)
|
|
|
* 'objects': Variables Simplify. (line 14)
|
|
|
* 'OBJECTS': Variables Simplify. (line 20)
|
|
|
* objects, loaded: Loading Objects. (line 6)
|
|
|
* 'objs': Variables Simplify. (line 20)
|
|
|
* 'OBJS': Variables Simplify. (line 20)
|
|
|
* old-fashioned suffix rules: Suffix Rules. (line 6)
|
|
|
* options: Options Summary. (line 6)
|
|
|
* options, and recursion: Options/Recursion. (line 6)
|
|
|
* options, setting from environment: Options/Recursion. (line 81)
|
|
|
* options, setting in makefiles: Options/Recursion. (line 81)
|
|
|
* order of pattern rules: Pattern Match. (line 30)
|
|
|
* order-only prerequisites: Prerequisite Types. (line 6)
|
|
|
* origin of variable: Origin Function. (line 6)
|
|
|
* output during parallel execution: Parallel Output. (line 6)
|
|
|
* output during parallel execution <1>: Options Summary. (line 171)
|
|
|
* overriding makefiles: Overriding Makefiles.
|
|
|
(line 6)
|
|
|
* overriding variables with arguments: Overriding. (line 6)
|
|
|
* overriding with 'override': Override Directive. (line 6)
|
|
|
* parallel execution: Parallel. (line 6)
|
|
|
* parallel execution, and archive update: Archive Pitfalls. (line 6)
|
|
|
* parallel execution, input during: Parallel Input. (line 6)
|
|
|
* parallel execution, output during: Parallel Output. (line 6)
|
|
|
* parallel execution, output during <1>: Options Summary. (line 171)
|
|
|
* parallel execution, overriding: Special Targets. (line 142)
|
|
|
* parallel output to terminal: Terminal Output. (line 6)
|
|
|
* parts of makefile rule: Rule Introduction. (line 6)
|
|
|
* Pascal, rule to compile: Catalogue of Rules. (line 45)
|
|
|
* pattern rule: Pattern Intro. (line 6)
|
|
|
* pattern rule, expansion: Reading Makefiles. (line 92)
|
|
|
* pattern rules, order of: Pattern Match. (line 30)
|
|
|
* pattern rules, static (not implicit): Static Pattern. (line 6)
|
|
|
* pattern rules, static, syntax of: Static Usage. (line 6)
|
|
|
* pattern-specific variables: Pattern-specific. (line 6)
|
|
|
* pc: Catalogue of Rules. (line 45)
|
|
|
* pc <1>: Implicit Variables. (line 63)
|
|
|
* phony targets: Phony Targets. (line 6)
|
|
|
* phony targets and recipe execution: Instead of Execution.
|
|
|
(line 75)
|
|
|
* pitfalls of wildcards: Wildcard Pitfall. (line 6)
|
|
|
* plugin_is_GPL_compatible: Loaded Object API. (line 31)
|
|
|
* portability: Features. (line 6)
|
|
|
* POSIX: Overview. (line 13)
|
|
|
* POSIX <1>: Options/Recursion. (line 61)
|
|
|
* POSIX-conforming mode, setting: Special Targets. (line 157)
|
|
|
* post-installation commands: Install Command Categories.
|
|
|
(line 6)
|
|
|
* pre-installation commands: Install Command Categories.
|
|
|
(line 6)
|
|
|
* precious targets: Special Targets. (line 32)
|
|
|
* predefined rules and variables, printing: Options Summary. (line 187)
|
|
|
* prefix, adding: File Name Functions. (line 78)
|
|
|
* prerequisite: Rules. (line 6)
|
|
|
* prerequisite pattern, implicit: Pattern Intro. (line 22)
|
|
|
* prerequisite pattern, static (not implicit): Static Usage. (line 30)
|
|
|
* prerequisite types: Prerequisite Types. (line 6)
|
|
|
* prerequisite, expansion: Reading Makefiles. (line 92)
|
|
|
* prerequisites: Rule Syntax. (line 47)
|
|
|
* prerequisites, and automatic variables: Automatic Variables.
|
|
|
(line 17)
|
|
|
* prerequisites, automatic generation: Include. (line 51)
|
|
|
* prerequisites, automatic generation <1>: Automatic Prerequisites.
|
|
|
(line 6)
|
|
|
* prerequisites, introduction to: Rule Introduction. (line 8)
|
|
|
* prerequisites, list of all: Automatic Variables. (line 61)
|
|
|
* prerequisites, list of changed: Automatic Variables. (line 51)
|
|
|
* prerequisites, normal: Prerequisite Types. (line 6)
|
|
|
* prerequisites, order-only: Prerequisite Types. (line 6)
|
|
|
* prerequisites, varying (static pattern): Static Pattern. (line 6)
|
|
|
* preserving intermediate files: Chained Rules. (line 46)
|
|
|
* preserving with '.PRECIOUS': Special Targets. (line 32)
|
|
|
* preserving with '.PRECIOUS' <1>: Chained Rules. (line 56)
|
|
|
* preserving with '.SECONDARY': Special Targets. (line 54)
|
|
|
* 'print' (standard target): Goals. (line 98)
|
|
|
* 'print' target: Wildcard Examples. (line 21)
|
|
|
* 'print' target <1>: Empty Targets. (line 25)
|
|
|
* printing directories: -w Option. (line 6)
|
|
|
* printing messages: Make Control Functions.
|
|
|
(line 43)
|
|
|
* printing of recipes: Echoing. (line 6)
|
|
|
* printing user warnings: Make Control Functions.
|
|
|
(line 35)
|
|
|
* problems and bugs, reporting: Bugs. (line 6)
|
|
|
* problems with wildcards: Wildcard Pitfall. (line 6)
|
|
|
* processing a makefile: How Make Works. (line 6)
|
|
|
* question mode: Instead of Execution.
|
|
|
(line 32)
|
|
|
* quoting '%', in 'patsubst': Text Functions. (line 26)
|
|
|
* quoting '%', in static pattern: Static Usage. (line 37)
|
|
|
* quoting '%', in 'vpath': Selective Search. (line 39)
|
|
|
* quoting newline, in makefile: Simple Makefile. (line 41)
|
|
|
* quoting newline, in recipes: Splitting Recipe Lines.
|
|
|
(line 6)
|
|
|
* Ratfor, rule to compile: Catalogue of Rules. (line 49)
|
|
|
* RCS, rule to extract from: Catalogue of Rules. (line 163)
|
|
|
* reading from a file: File Function. (line 6)
|
|
|
* reading makefiles: Reading Makefiles. (line 6)
|
|
|
* 'README': Makefile Names. (line 9)
|
|
|
* 'realclean' (standard target): Goals. (line 86)
|
|
|
* realpath: File Name Functions. (line 113)
|
|
|
* recipe: Simple Makefile. (line 74)
|
|
|
* recipe execution, single invocation: Special Targets. (line 150)
|
|
|
* recipe lines, single shell: One Shell. (line 6)
|
|
|
* recipe syntax: Recipe Syntax. (line 6)
|
|
|
* recipe, execution: Execution. (line 6)
|
|
|
* recipes: Rule Syntax. (line 25)
|
|
|
* recipes <1>: Recipes. (line 6)
|
|
|
* recipes setting shell variables: Execution. (line 12)
|
|
|
* recipes, and directory search: Recipes/Search. (line 6)
|
|
|
* recipes, backslash ('\') in: Splitting Recipe Lines.
|
|
|
(line 6)
|
|
|
* recipes, canned: Canned Recipes. (line 6)
|
|
|
* recipes, comments in: Recipe Syntax. (line 29)
|
|
|
* recipes, echoing: Echoing. (line 6)
|
|
|
* recipes, empty: Empty Recipes. (line 6)
|
|
|
* recipes, errors in: Errors. (line 6)
|
|
|
* recipes, execution in parallel: Parallel. (line 6)
|
|
|
* recipes, how to write: Recipes. (line 6)
|
|
|
* recipes, instead of executing: Instead of Execution.
|
|
|
(line 6)
|
|
|
* recipes, introduction to: Rule Introduction. (line 8)
|
|
|
* recipes, quoting newlines in: Splitting Recipe Lines.
|
|
|
(line 6)
|
|
|
* recipes, splitting: Splitting Recipe Lines.
|
|
|
(line 6)
|
|
|
* recipes, using variables in: Variables in Recipes.
|
|
|
(line 6)
|
|
|
* recompilation: Introduction. (line 22)
|
|
|
* recompilation, avoiding: Avoiding Compilation.
|
|
|
(line 6)
|
|
|
* recording events with empty targets: Empty Targets. (line 6)
|
|
|
* recursion: Recursion. (line 6)
|
|
|
* recursion, and '-C': Options/Recursion. (line 22)
|
|
|
* recursion, and '-f': Options/Recursion. (line 22)
|
|
|
* recursion, and '-j': Options/Recursion. (line 25)
|
|
|
* recursion, and '-o': Options/Recursion. (line 22)
|
|
|
* recursion, and '-t': MAKE Variable. (line 35)
|
|
|
* recursion, and '-W': Options/Recursion. (line 22)
|
|
|
* recursion, and '-w': -w Option. (line 20)
|
|
|
* recursion, and command line variable definitions: Options/Recursion.
|
|
|
(line 17)
|
|
|
* recursion, and environment: Variables/Recursion. (line 6)
|
|
|
* recursion, and 'MAKE' variable: MAKE Variable. (line 6)
|
|
|
* recursion, and 'MAKEFILES' variable: MAKEFILES Variable. (line 15)
|
|
|
* recursion, and options: Options/Recursion. (line 6)
|
|
|
* recursion, and printing directories: -w Option. (line 6)
|
|
|
* recursion, and variables: Variables/Recursion. (line 6)
|
|
|
* recursion, level of: Variables/Recursion. (line 114)
|
|
|
* recursive variable expansion: Using Variables. (line 6)
|
|
|
* recursive variable expansion <1>: Flavors. (line 6)
|
|
|
* recursively expanded variables: Flavors. (line 6)
|
|
|
* reference to variables: Reference. (line 6)
|
|
|
* reference to variables <1>: Advanced. (line 6)
|
|
|
* relinking: How Make Works. (line 46)
|
|
|
* remaking loaded objects: Remaking Loaded Objects.
|
|
|
(line 6)
|
|
|
* remaking makefiles: Remaking Makefiles. (line 6)
|
|
|
* removal of target files: Errors. (line 64)
|
|
|
* removal of target files <1>: Interrupts. (line 6)
|
|
|
* removing duplicate words: Text Functions. (line 155)
|
|
|
* removing targets on failure: Special Targets. (line 71)
|
|
|
* removing, to clean up: Cleanup. (line 6)
|
|
|
* reporting bugs: Bugs. (line 6)
|
|
|
* rm: Implicit Variables. (line 106)
|
|
|
* 'rm' (shell command): Simple Makefile. (line 85)
|
|
|
* 'rm' (shell command) <1>: Wildcard Examples. (line 12)
|
|
|
* 'rm' (shell command) <2>: Phony Targets. (line 20)
|
|
|
* 'rm' (shell command) <3>: Errors. (line 27)
|
|
|
* rule prerequisites: Rule Syntax. (line 47)
|
|
|
* rule syntax: Rule Syntax. (line 6)
|
|
|
* rule targets: Rule Syntax. (line 18)
|
|
|
* rule, double-colon ('::'): Double-Colon. (line 6)
|
|
|
* rule, explicit, definition of: Makefile Contents. (line 10)
|
|
|
* rule, how to write: Rules. (line 6)
|
|
|
* rule, implicit: Implicit Rules. (line 6)
|
|
|
* rule, implicit, and directory search: Implicit/Search. (line 6)
|
|
|
* rule, implicit, and 'VPATH': Implicit/Search. (line 6)
|
|
|
* rule, implicit, chains of: Chained Rules. (line 6)
|
|
|
* rule, implicit, definition of: Makefile Contents. (line 16)
|
|
|
* rule, implicit, how to use: Using Implicit. (line 6)
|
|
|
* rule, implicit, introduction to: make Deduces. (line 6)
|
|
|
* rule, implicit, predefined: Catalogue of Rules. (line 6)
|
|
|
* rule, introduction to: Rule Introduction. (line 6)
|
|
|
* rule, multiple for one target: Multiple Rules. (line 6)
|
|
|
* rule, no recipe or prerequisites: Force Targets. (line 6)
|
|
|
* rule, pattern: Pattern Intro. (line 6)
|
|
|
* rule, static pattern: Static Pattern. (line 6)
|
|
|
* rule, static pattern versus implicit: Static versus Implicit.
|
|
|
(line 6)
|
|
|
* rule, with multiple targets: Multiple Targets. (line 6)
|
|
|
* rules, and '$': Rule Syntax. (line 33)
|
|
|
* s. (SCCS file prefix): Catalogue of Rules. (line 172)
|
|
|
* SCCS, rule to extract from: Catalogue of Rules. (line 172)
|
|
|
* search algorithm, implicit rule: Implicit Rule Search.
|
|
|
(line 6)
|
|
|
* search path for prerequisites ('VPATH'): Directory Search. (line 6)
|
|
|
* search path for prerequisites ('VPATH'), and implicit rules: Implicit/Search.
|
|
|
(line 6)
|
|
|
* search path for prerequisites ('VPATH'), and link libraries: Libraries/Search.
|
|
|
(line 6)
|
|
|
* searching for strings: Text Functions. (line 104)
|
|
|
* secondary expansion: Secondary Expansion. (line 6)
|
|
|
* secondary expansion and explicit rules: Secondary Expansion.
|
|
|
(line 104)
|
|
|
* secondary expansion and implicit rules: Secondary Expansion.
|
|
|
(line 144)
|
|
|
* secondary expansion and static pattern rules: Secondary Expansion.
|
|
|
(line 136)
|
|
|
* secondary files: Chained Rules. (line 46)
|
|
|
* secondary targets: Special Targets. (line 54)
|
|
|
* 'sed' (shell command): Automatic Prerequisites.
|
|
|
(line 72)
|
|
|
* selecting a word: Text Functions. (line 159)
|
|
|
* selecting word lists: Text Functions. (line 168)
|
|
|
* sequences of commands: Canned Recipes. (line 6)
|
|
|
* setting options from environment: Options/Recursion. (line 81)
|
|
|
* setting options in makefiles: Options/Recursion. (line 81)
|
|
|
* setting variables: Setting. (line 6)
|
|
|
* several rules for one target: Multiple Rules. (line 6)
|
|
|
* several targets in a rule: Multiple Targets. (line 6)
|
|
|
* 'shar' (standard target): Goals. (line 104)
|
|
|
* shell command, function for: Shell Function. (line 6)
|
|
|
* shell file name pattern (in 'include'): Include. (line 13)
|
|
|
* shell variables, setting in recipes: Execution. (line 12)
|
|
|
* shell wildcards (in 'include'): Include. (line 13)
|
|
|
* shell, choosing the: Choosing the Shell. (line 6)
|
|
|
* SHELL, exported value: Variables/Recursion. (line 23)
|
|
|
* SHELL, import from environment: Environment. (line 37)
|
|
|
* shell, in DOS and Windows: Choosing the Shell. (line 38)
|
|
|
* 'SHELL', MS-DOS specifics: Choosing the Shell. (line 44)
|
|
|
* 'SHELL', value of: Choosing the Shell. (line 6)
|
|
|
* signal: Interrupts. (line 6)
|
|
|
* silent operation: Echoing. (line 6)
|
|
|
* simple makefile: Simple Makefile. (line 6)
|
|
|
* simple variable expansion: Using Variables. (line 6)
|
|
|
* simplifying with variables: Variables Simplify. (line 6)
|
|
|
* simply expanded variables: Flavors. (line 56)
|
|
|
* sorting words: Text Functions. (line 147)
|
|
|
* spaces, in variable values: Flavors. (line 107)
|
|
|
* spaces, stripping: Text Functions. (line 80)
|
|
|
* special targets: Special Targets. (line 6)
|
|
|
* special variables: Special Variables. (line 6)
|
|
|
* specifying makefile name: Makefile Names. (line 31)
|
|
|
* splitting long lines: Splitting Lines. (line 6)
|
|
|
* splitting recipes: Splitting Recipe Lines.
|
|
|
(line 6)
|
|
|
* staged installs: DESTDIR. (line 6)
|
|
|
* standard input: Parallel Input. (line 6)
|
|
|
* standards conformance: Overview. (line 13)
|
|
|
* standards for makefiles: Makefile Conventions.
|
|
|
(line 6)
|
|
|
* static pattern rule: Static Pattern. (line 6)
|
|
|
* static pattern rule, syntax of: Static Usage. (line 6)
|
|
|
* static pattern rule, versus implicit: Static versus Implicit.
|
|
|
(line 6)
|
|
|
* static pattern rules, secondary expansion of: Secondary Expansion.
|
|
|
(line 136)
|
|
|
* stem: Static Usage. (line 17)
|
|
|
* stem <1>: Pattern Match. (line 6)
|
|
|
* stem, shortest: Pattern Match. (line 38)
|
|
|
* stem, variable for: Automatic Variables. (line 77)
|
|
|
* stopping make: Make Control Functions.
|
|
|
(line 11)
|
|
|
* strings, searching for: Text Functions. (line 104)
|
|
|
* stripping whitespace: Text Functions. (line 80)
|
|
|
* sub-'make': Variables/Recursion. (line 6)
|
|
|
* subdirectories, recursion for: Recursion. (line 6)
|
|
|
* substitution variable reference: Substitution Refs. (line 6)
|
|
|
* suffix rule: Suffix Rules. (line 6)
|
|
|
* suffix rule, for archive: Archive Suffix Rules.
|
|
|
(line 6)
|
|
|
* suffix, adding: File Name Functions. (line 67)
|
|
|
* suffix, function to find: File Name Functions. (line 42)
|
|
|
* suffix, substituting in variables: Substitution Refs. (line 6)
|
|
|
* suppressing inheritance: Suppressing Inheritance.
|
|
|
(line 6)
|
|
|
* switches: Options Summary. (line 6)
|
|
|
* symbol directories, updating archive: Archive Symbols. (line 6)
|
|
|
* syntax of recipe: Recipe Syntax. (line 6)
|
|
|
* syntax of rules: Rule Syntax. (line 6)
|
|
|
* tab character (in commands): Rule Syntax. (line 25)
|
|
|
* tabs in rules: Rule Introduction. (line 21)
|
|
|
* 'TAGS' (standard target): Goals. (line 112)
|
|
|
* tangle: Catalogue of Rules. (line 149)
|
|
|
* tangle <1>: Implicit Variables. (line 100)
|
|
|
* 'tar' (standard target): Goals. (line 101)
|
|
|
* target: Rules. (line 6)
|
|
|
* target pattern, implicit: Pattern Intro. (line 9)
|
|
|
* target pattern, static (not implicit): Static Usage. (line 17)
|
|
|
* target, deleting on error: Errors. (line 64)
|
|
|
* target, deleting on interrupt: Interrupts. (line 6)
|
|
|
* target, expansion: Reading Makefiles. (line 92)
|
|
|
* target, multiple in pattern rule: Pattern Intro. (line 53)
|
|
|
* target, multiple rules for one: Multiple Rules. (line 6)
|
|
|
* target, touching: Instead of Execution.
|
|
|
(line 24)
|
|
|
* target-specific variables: Target-specific. (line 6)
|
|
|
* targets: Rule Syntax. (line 18)
|
|
|
* targets without a file: Phony Targets. (line 6)
|
|
|
* targets, built-in special: Special Targets. (line 6)
|
|
|
* targets, empty: Empty Targets. (line 6)
|
|
|
* targets, force: Force Targets. (line 6)
|
|
|
* targets, introduction to: Rule Introduction. (line 8)
|
|
|
* targets, multiple: Multiple Targets. (line 6)
|
|
|
* targets, phony: Phony Targets. (line 6)
|
|
|
* terminal rule: Match-Anything Rules.
|
|
|
(line 6)
|
|
|
* terminal, output to: Terminal Output. (line 6)
|
|
|
* 'test' (standard target): Goals. (line 116)
|
|
|
* testing compilation: Testing. (line 6)
|
|
|
* tex: Catalogue of Rules. (line 149)
|
|
|
* tex <1>: Implicit Variables. (line 87)
|
|
|
* TeX, rule to run: Catalogue of Rules. (line 149)
|
|
|
* texi2dvi: Catalogue of Rules. (line 156)
|
|
|
* texi2dvi <1>: Implicit Variables. (line 91)
|
|
|
* Texinfo, rule to format: Catalogue of Rules. (line 156)
|
|
|
* tilde ('~'): Wildcards. (line 11)
|
|
|
* tools, sharing job slots: Job Slots. (line 6)
|
|
|
* 'touch' (shell command): Wildcard Examples. (line 21)
|
|
|
* 'touch' (shell command) <1>: Empty Targets. (line 25)
|
|
|
* touching files: Instead of Execution.
|
|
|
(line 24)
|
|
|
* traditional directory search (GPATH): Search Algorithm. (line 42)
|
|
|
* types of prerequisites: Prerequisite Types. (line 6)
|
|
|
* types, conversion of: Guile Types. (line 6)
|
|
|
* undefined variables, warning message: Options Summary. (line 292)
|
|
|
* undefining variable: Undefine Directive. (line 6)
|
|
|
* updating archive symbol directories: Archive Symbols. (line 6)
|
|
|
* updating loaded objects: Remaking Loaded Objects.
|
|
|
(line 6)
|
|
|
* updating makefiles: Remaking Makefiles. (line 6)
|
|
|
* user defined functions: Call Function. (line 6)
|
|
|
* value: Using Variables. (line 6)
|
|
|
* value, how a variable gets it: Values. (line 6)
|
|
|
* variable: Using Variables. (line 6)
|
|
|
* variable definition: Makefile Contents. (line 22)
|
|
|
* variable references in recipes: Variables in Recipes.
|
|
|
(line 6)
|
|
|
* variables: Variables Simplify. (line 6)
|
|
|
* variables, '$' in name: Computed Names. (line 6)
|
|
|
* variables, and implicit rule: Automatic Variables. (line 6)
|
|
|
* variables, appending to: Appending. (line 6)
|
|
|
* variables, automatic: Automatic Variables. (line 6)
|
|
|
* variables, command line: Overriding. (line 6)
|
|
|
* variables, command line, and recursion: Options/Recursion. (line 17)
|
|
|
* variables, computed names: Computed Names. (line 6)
|
|
|
* variables, conditional assignment: Flavors. (line 135)
|
|
|
* variables, defining verbatim: Multi-Line. (line 6)
|
|
|
* variables, environment: Variables/Recursion. (line 6)
|
|
|
* variables, environment <1>: Environment. (line 6)
|
|
|
* variables, exporting: Variables/Recursion. (line 6)
|
|
|
* variables, flavor of: Flavor Function. (line 6)
|
|
|
* variables, flavors: Flavors. (line 6)
|
|
|
* variables, how they get their values: Values. (line 6)
|
|
|
* variables, how to reference: Reference. (line 6)
|
|
|
* variables, loops in expansion: Flavors. (line 44)
|
|
|
* variables, modified reference: Substitution Refs. (line 6)
|
|
|
* variables, multi-line: Multi-Line. (line 6)
|
|
|
* variables, nested references: Computed Names. (line 6)
|
|
|
* variables, origin of: Origin Function. (line 6)
|
|
|
* variables, overriding: Override Directive. (line 6)
|
|
|
* variables, overriding with arguments: Overriding. (line 6)
|
|
|
* variables, pattern-specific: Pattern-specific. (line 6)
|
|
|
* variables, recursively expanded: Flavors. (line 6)
|
|
|
* variables, setting: Setting. (line 6)
|
|
|
* variables, simply expanded: Flavors. (line 56)
|
|
|
* variables, spaces in values: Flavors. (line 107)
|
|
|
* variables, substituting suffix in: Substitution Refs. (line 6)
|
|
|
* variables, substitution reference: Substitution Refs. (line 6)
|
|
|
* variables, target-specific: Target-specific. (line 6)
|
|
|
* variables, unexpanded value: Value Function. (line 6)
|
|
|
* variables, warning for undefined: Options Summary. (line 292)
|
|
|
* varying prerequisites: Static Pattern. (line 6)
|
|
|
* verbatim variable definition: Multi-Line. (line 6)
|
|
|
* vpath: Directory Search. (line 6)
|
|
|
* 'VPATH', and implicit rules: Implicit/Search. (line 6)
|
|
|
* 'VPATH', and link libraries: Libraries/Search. (line 6)
|
|
|
* warnings, printing: Make Control Functions.
|
|
|
(line 35)
|
|
|
* weave: Catalogue of Rules. (line 149)
|
|
|
* weave <1>: Implicit Variables. (line 94)
|
|
|
* Web, rule to run: Catalogue of Rules. (line 149)
|
|
|
* what if: Instead of Execution.
|
|
|
(line 41)
|
|
|
* whitespace, in variable values: Flavors. (line 107)
|
|
|
* whitespace, stripping: Text Functions. (line 80)
|
|
|
* wildcard: Wildcards. (line 6)
|
|
|
* wildcard pitfalls: Wildcard Pitfall. (line 6)
|
|
|
* wildcard, function: File Name Functions. (line 106)
|
|
|
* wildcard, in archive member: Archive Members. (line 36)
|
|
|
* wildcard, in 'include': Include. (line 13)
|
|
|
* wildcards and MS-DOS/MS-Windows backslashes: Wildcard Pitfall.
|
|
|
(line 31)
|
|
|
* Windows, choosing a shell in: Choosing the Shell. (line 38)
|
|
|
* word, selecting a: Text Functions. (line 159)
|
|
|
* words, extracting first: Text Functions. (line 185)
|
|
|
* words, extracting last: Text Functions. (line 198)
|
|
|
* words, filtering: Text Functions. (line 115)
|
|
|
* words, filtering out: Text Functions. (line 133)
|
|
|
* words, finding number: Text Functions. (line 180)
|
|
|
* words, iterating over: Foreach Function. (line 6)
|
|
|
* words, joining lists: File Name Functions. (line 89)
|
|
|
* words, removing duplicates: Text Functions. (line 155)
|
|
|
* words, selecting lists of: Text Functions. (line 168)
|
|
|
* writing recipes: Recipes. (line 6)
|
|
|
* writing rules: Rules. (line 6)
|
|
|
* writing to a file: File Function. (line 6)
|
|
|
* yacc: Catalogue of Rules. (line 117)
|
|
|
* yacc <1>: Implicit Variables. (line 77)
|
|
|
* 'yacc': Canned Recipes. (line 18)
|
|
|
* Yacc, rule to run: Catalogue of Rules. (line 117)
|
|
|
|
|
|
|
|
|
File: make.info, Node: Name Index, Prev: Concept Index, Up: Top
|
|
|
|
|
|
Index of Functions, Variables, & Directives
|
|
|
*******************************************
|
|
|
|
|
|
[index ]
|
|
|
* Menu:
|
|
|
|
|
|
* $%: Automatic Variables. (line 37)
|
|
|
* $(%D): Automatic Variables. (line 129)
|
|
|
* $(%F): Automatic Variables. (line 130)
|
|
|
* $(*D): Automatic Variables. (line 124)
|
|
|
* $(*F): Automatic Variables. (line 125)
|
|
|
* $(+D): Automatic Variables. (line 147)
|
|
|
* $(+F): Automatic Variables. (line 148)
|
|
|
* $(<D): Automatic Variables. (line 137)
|
|
|
* $(<F): Automatic Variables. (line 138)
|
|
|
* $(?D): Automatic Variables. (line 153)
|
|
|
* $(?F): Automatic Variables. (line 154)
|
|
|
* $(@D): Automatic Variables. (line 113)
|
|
|
* $(@F): Automatic Variables. (line 119)
|
|
|
* $(^D): Automatic Variables. (line 142)
|
|
|
* $(^F): Automatic Variables. (line 143)
|
|
|
* $*: Automatic Variables. (line 73)
|
|
|
* $*, and static pattern: Static Usage. (line 82)
|
|
|
* $+: Automatic Variables. (line 63)
|
|
|
* $<: Automatic Variables. (line 43)
|
|
|
* $?: Automatic Variables. (line 48)
|
|
|
* $@: Automatic Variables. (line 30)
|
|
|
* $^: Automatic Variables. (line 53)
|
|
|
* $|: Automatic Variables. (line 69)
|
|
|
* % (automatic variable): Automatic Variables. (line 37)
|
|
|
* %D (automatic variable): Automatic Variables. (line 129)
|
|
|
* %F (automatic variable): Automatic Variables. (line 130)
|
|
|
* * (automatic variable): Automatic Variables. (line 73)
|
|
|
* * (automatic variable), unsupported bizarre usage: Missing. (line 44)
|
|
|
* *D (automatic variable): Automatic Variables. (line 124)
|
|
|
* *F (automatic variable): Automatic Variables. (line 125)
|
|
|
* + (automatic variable): Automatic Variables. (line 63)
|
|
|
* +D (automatic variable): Automatic Variables. (line 147)
|
|
|
* +F (automatic variable): Automatic Variables. (line 148)
|
|
|
* -load: load Directive. (line 65)
|
|
|
* .DEFAULT: Special Targets. (line 22)
|
|
|
* .DEFAULT <1>: Last Resort. (line 23)
|
|
|
* .DEFAULT, and empty recipes: Empty Recipes. (line 16)
|
|
|
* .DEFAULT_GOAL (define default goal): Special Variables. (line 34)
|
|
|
* .DELETE_ON_ERROR: Special Targets. (line 70)
|
|
|
* .DELETE_ON_ERROR <1>: Errors. (line 64)
|
|
|
* .EXPORT_ALL_VARIABLES: Special Targets. (line 135)
|
|
|
* .EXPORT_ALL_VARIABLES <1>: Variables/Recursion. (line 99)
|
|
|
* .FEATURES (list of supported features): Special Variables. (line 121)
|
|
|
* .IGNORE: Special Targets. (line 77)
|
|
|
* .IGNORE <1>: Errors. (line 30)
|
|
|
* .INCLUDE_DIRS (list of include directories): Special Variables.
|
|
|
(line 174)
|
|
|
* .INTERMEDIATE: Special Targets. (line 47)
|
|
|
* .LIBPATTERNS: Libraries/Search. (line 6)
|
|
|
* .LOADED: load Directive. (line 62)
|
|
|
* .LOW_RESOLUTION_TIME: Special Targets. (line 90)
|
|
|
* .NOTPARALLEL: Special Targets. (line 141)
|
|
|
* .ONESHELL: Special Targets. (line 149)
|
|
|
* .ONESHELL <1>: One Shell. (line 6)
|
|
|
* .PHONY: Phony Targets. (line 22)
|
|
|
* .PHONY <1>: Special Targets. (line 8)
|
|
|
* .POSIX: Special Targets. (line 156)
|
|
|
* .POSIX <1>: Options/Recursion. (line 61)
|
|
|
* .PRECIOUS: Special Targets. (line 31)
|
|
|
* .PRECIOUS <1>: Interrupts. (line 22)
|
|
|
* .RECIPEPREFIX (change the recipe prefix character): Special Variables.
|
|
|
(line 99)
|
|
|
* .SECONDARY: Special Targets. (line 53)
|
|
|
* .SECONDEXPANSION: Secondary Expansion. (line 6)
|
|
|
* .SECONDEXPANSION <1>: Special Targets. (line 63)
|
|
|
* .SHELLFLAGS: Choosing the Shell. (line 6)
|
|
|
* .SHELLFLAGS <1>: Choosing the Shell. (line 87)
|
|
|
* .SHELLSTATUS: Shell Function. (line 25)
|
|
|
* .SILENT: Special Targets. (line 121)
|
|
|
* .SILENT <1>: Echoing. (line 24)
|
|
|
* .SUFFIXES: Special Targets. (line 16)
|
|
|
* .SUFFIXES <1>: Suffix Rules. (line 61)
|
|
|
* .VARIABLES (list of variables): Special Variables. (line 112)
|
|
|
* /usr/gnu/include: Include. (line 53)
|
|
|
* /usr/include: Include. (line 53)
|
|
|
* /usr/local/include: Include. (line 53)
|
|
|
* < (automatic variable): Automatic Variables. (line 43)
|
|
|
* <D (automatic variable): Automatic Variables. (line 137)
|
|
|
* <F (automatic variable): Automatic Variables. (line 138)
|
|
|
* ? (automatic variable): Automatic Variables. (line 48)
|
|
|
* ?D (automatic variable): Automatic Variables. (line 153)
|
|
|
* ?F (automatic variable): Automatic Variables. (line 154)
|
|
|
* @ (automatic variable): Automatic Variables. (line 30)
|
|
|
* @D (automatic variable): Automatic Variables. (line 113)
|
|
|
* @F (automatic variable): Automatic Variables. (line 119)
|
|
|
* ^ (automatic variable): Automatic Variables. (line 53)
|
|
|
* ^D (automatic variable): Automatic Variables. (line 142)
|
|
|
* ^F (automatic variable): Automatic Variables. (line 143)
|
|
|
* | (automatic variable): Automatic Variables. (line 69)
|
|
|
* abspath: File Name Functions. (line 120)
|
|
|
* addprefix: File Name Functions. (line 78)
|
|
|
* addsuffix: File Name Functions. (line 67)
|
|
|
* and: Conditional Functions.
|
|
|
(line 45)
|
|
|
* AR: Implicit Variables. (line 40)
|
|
|
* ARFLAGS: Implicit Variables. (line 113)
|
|
|
* AS: Implicit Variables. (line 43)
|
|
|
* ASFLAGS: Implicit Variables. (line 116)
|
|
|
* basename: File Name Functions. (line 56)
|
|
|
* bindir: Directory Variables. (line 57)
|
|
|
* call: Call Function. (line 6)
|
|
|
* CC: Implicit Variables. (line 46)
|
|
|
* CFLAGS: Implicit Variables. (line 120)
|
|
|
* CO: Implicit Variables. (line 66)
|
|
|
* COFLAGS: Implicit Variables. (line 126)
|
|
|
* COMSPEC: Choosing the Shell. (line 41)
|
|
|
* CPP: Implicit Variables. (line 52)
|
|
|
* CPPFLAGS: Implicit Variables. (line 129)
|
|
|
* CTANGLE: Implicit Variables. (line 103)
|
|
|
* 'CURDIR': Recursion. (line 28)
|
|
|
* CWEAVE: Implicit Variables. (line 97)
|
|
|
* CXX: Implicit Variables. (line 49)
|
|
|
* CXXFLAGS: Implicit Variables. (line 123)
|
|
|
* define: Multi-Line. (line 6)
|
|
|
* DESTDIR: DESTDIR. (line 6)
|
|
|
* dir: File Name Functions. (line 16)
|
|
|
* else: Conditional Syntax. (line 6)
|
|
|
* endef: Multi-Line. (line 6)
|
|
|
* endif: Conditional Syntax. (line 6)
|
|
|
* error: Make Control Functions.
|
|
|
(line 11)
|
|
|
* eval: Eval Function. (line 6)
|
|
|
* exec_prefix: Directory Variables. (line 39)
|
|
|
* export: Variables/Recursion. (line 40)
|
|
|
* FC: Implicit Variables. (line 56)
|
|
|
* FFLAGS: Implicit Variables. (line 133)
|
|
|
* file: File Function. (line 6)
|
|
|
* filter: Text Functions. (line 115)
|
|
|
* filter-out: Text Functions. (line 133)
|
|
|
* findstring: Text Functions. (line 104)
|
|
|
* firstword: Text Functions. (line 185)
|
|
|
* flavor: Flavor Function. (line 6)
|
|
|
* foreach: Foreach Function. (line 6)
|
|
|
* GET: Implicit Variables. (line 69)
|
|
|
* GFLAGS: Implicit Variables. (line 136)
|
|
|
* gmk-eval: Guile Interface. (line 18)
|
|
|
* gmk-expand: Guile Interface. (line 12)
|
|
|
* gmk_add_function: Loaded Object API. (line 53)
|
|
|
* gmk_alloc: Loaded Object API. (line 149)
|
|
|
* gmk_eval: Loaded Object API. (line 123)
|
|
|
* gmk_expand: Loaded Object API. (line 117)
|
|
|
* gmk_free: Loaded Object API. (line 154)
|
|
|
* gmk_func_ptr: Loaded Object API. (line 95)
|
|
|
* GNUmakefile: Makefile Names. (line 7)
|
|
|
* GPATH: Search Algorithm. (line 48)
|
|
|
* guile: Guile Function. (line 6)
|
|
|
* if: Conditional Functions.
|
|
|
(line 6)
|
|
|
* if <1>: Conditional Functions.
|
|
|
(line 12)
|
|
|
* ifdef: Conditional Syntax. (line 6)
|
|
|
* ifeq: Conditional Syntax. (line 6)
|
|
|
* ifndef: Conditional Syntax. (line 6)
|
|
|
* ifneq: Conditional Syntax. (line 6)
|
|
|
* include: Include. (line 6)
|
|
|
* info: Make Control Functions.
|
|
|
(line 43)
|
|
|
* join: File Name Functions. (line 89)
|
|
|
* lastword: Text Functions. (line 198)
|
|
|
* LDFLAGS: Implicit Variables. (line 139)
|
|
|
* LDLIBS: Implicit Variables. (line 144)
|
|
|
* LEX: Implicit Variables. (line 72)
|
|
|
* LFLAGS: Implicit Variables. (line 150)
|
|
|
* libexecdir: Directory Variables. (line 70)
|
|
|
* LINT: Implicit Variables. (line 80)
|
|
|
* LINTFLAGS: Implicit Variables. (line 162)
|
|
|
* load: load Directive. (line 9)
|
|
|
* LOADLIBES: Implicit Variables. (line 144)
|
|
|
* M2C: Implicit Variables. (line 60)
|
|
|
* MAKE: MAKE Variable. (line 6)
|
|
|
* MAKE <1>: Flavors. (line 88)
|
|
|
* MAKECMDGOALS: Goals. (line 30)
|
|
|
* Makefile: Makefile Names. (line 7)
|
|
|
* makefile: Makefile Names. (line 7)
|
|
|
* MAKEFILES: MAKEFILES Variable. (line 6)
|
|
|
* MAKEFILES <1>: Variables/Recursion. (line 126)
|
|
|
* MAKEFILE_LIST (list of parsed makefiles): Special Variables.
|
|
|
(line 8)
|
|
|
* MAKEFLAGS: Options/Recursion. (line 6)
|
|
|
* MAKEINFO: Implicit Variables. (line 83)
|
|
|
* MAKELEVEL: Variables/Recursion. (line 114)
|
|
|
* MAKELEVEL <1>: Flavors. (line 88)
|
|
|
* MAKEOVERRIDES: Options/Recursion. (line 50)
|
|
|
* 'MAKESHELL' (MS-DOS alternative to 'SHELL'): Choosing the Shell.
|
|
|
(line 27)
|
|
|
* MAKE_HOST: Quick Reference. (line 348)
|
|
|
* MAKE_RESTARTS (number of times 'make' has restarted): Special Variables.
|
|
|
(line 73)
|
|
|
* MAKE_TERMERR (whether stderr is a terminal): Special Variables.
|
|
|
(line 80)
|
|
|
* MAKE_TERMOUT (whether stdout is a terminal): Special Variables.
|
|
|
(line 80)
|
|
|
* MAKE_VERSION: Quick Reference. (line 343)
|
|
|
* MFLAGS: Options/Recursion. (line 66)
|
|
|
* notdir: File Name Functions. (line 26)
|
|
|
* or: Conditional Functions.
|
|
|
(line 37)
|
|
|
* origin: Origin Function. (line 6)
|
|
|
* OUTPUT_OPTION: Catalogue of Rules. (line 200)
|
|
|
* override: Override Directive. (line 6)
|
|
|
* patsubst: Substitution Refs. (line 28)
|
|
|
* patsubst <1>: Text Functions. (line 18)
|
|
|
* PC: Implicit Variables. (line 63)
|
|
|
* PFLAGS: Implicit Variables. (line 156)
|
|
|
* prefix: Directory Variables. (line 29)
|
|
|
* private: Suppressing Inheritance.
|
|
|
(line 6)
|
|
|
* realpath: File Name Functions. (line 113)
|
|
|
* RFLAGS: Implicit Variables. (line 159)
|
|
|
* RM: Implicit Variables. (line 106)
|
|
|
* sbindir: Directory Variables. (line 63)
|
|
|
* SHELL: Choosing the Shell. (line 6)
|
|
|
* SHELL <1>: Choosing the Shell. (line 88)
|
|
|
* shell: Shell Function. (line 6)
|
|
|
* 'SHELL' (recipe execution): Execution. (line 6)
|
|
|
* sort: Text Functions. (line 147)
|
|
|
* strip: Text Functions. (line 80)
|
|
|
* subst: Multiple Targets. (line 28)
|
|
|
* subst <1>: Text Functions. (line 9)
|
|
|
* suffix: File Name Functions. (line 42)
|
|
|
* SUFFIXES: Suffix Rules. (line 81)
|
|
|
* TANGLE: Implicit Variables. (line 100)
|
|
|
* TEX: Implicit Variables. (line 87)
|
|
|
* TEXI2DVI: Implicit Variables. (line 90)
|
|
|
* undefine: Undefine Directive. (line 6)
|
|
|
* unexport: Variables/Recursion. (line 45)
|
|
|
* value: Value Function. (line 6)
|
|
|
* VPATH: Directory Search. (line 6)
|
|
|
* VPATH <1>: General Search. (line 6)
|
|
|
* vpath: Directory Search. (line 6)
|
|
|
* vpath <1>: Selective Search. (line 6)
|
|
|
* warning: Make Control Functions.
|
|
|
(line 35)
|
|
|
* WEAVE: Implicit Variables. (line 94)
|
|
|
* wildcard: Wildcard Function. (line 6)
|
|
|
* wildcard <1>: File Name Functions. (line 106)
|
|
|
* word: Text Functions. (line 159)
|
|
|
* wordlist: Text Functions. (line 168)
|
|
|
* words: Text Functions. (line 180)
|
|
|
* YACC: Implicit Variables. (line 76)
|
|
|
* YFLAGS: Implicit Variables. (line 153)
|
|
|
|
