make.1

<B>Digital的Unix操作系统VAX 4.2源码</B>

.B \-f,
.B \-p, 
and
.B \-d
\) defined
for the command line.
Further, upon invocation,
.PN make
invents the variable if it is not in the
environment, puts the current options into it, and passes it on to
invocations of commands.
Thus, MAKEFLAGS always contains the
current input options.
This proves very useful for super-makes.
In fact, as noted above,
when the
.B \-n
option is used, the command $(MAKE)
is executed anyway.  Hence, one can perform a 
.PN make 
.B \-n
recursively on a whole software
system to see what would have been executed.
This is because the \fB\-n\fR
is put in MAKEFLAGS and passed to further invocations of $(MAKE).
This is one way of debugging
all of the makefiles for a software project
without actually doing anything.
.PP
.SS Macros
Macros can be defined in four different ways.  Some macros are defined
by default by
.PN make
internally.  All environment variables are assumed to be macro
definitions and macros can be defined in the makefile as well as on the 
.PN make
command line.  By default, the internal default macros are overridden by
environment variables, macros defined in the makefile override
environment variables and macros defined on the command line override
macros defined in the makefile.  The
.B \-e
option changes this such
that environment variables override macros defined in the makefile.
.PP
Entries of the form
.I string1  =  string2
are macro definitions.
.I String2
is defined as all characters up to a comment character or
an unescaped new-line.
Subsequent appearances of
.I $( string1 [: subst1 =[ subst2]])
are replaced by
.I string2 .
The parentheses are optional if a
single character macro name is used and
there is no substitute sequence.
The optional
.I : subst1 = subst2
is a substitute sequence.
If it is specified, all non-overlapping
occurrences of \fIsubst1\fR in the
named macro are replaced by \fIsubst2\fR.
The occurrence of \fIsubst1\fP must be a suffix at the end of the word
\fIstring1\fP.  Strings (for the purposes of this
type of substitution) are delimited by
blanks, tabs, new-line characters, and beginnings of lines.
An example of the use of the substitute sequence is shown under
.B Libraries.
.PP
The MACHINE macro is defined by 
.PN make
to allow for machine independent makefiles. The legal values are: 
.I vax
or 
.I mips.
.SS Internal Macros
There are five internally maintained macros which are useful
for writing rules for building targets.
.TP 15
.B $*
The macro \fB$*\fR stands for
the file name part of the current dependent with the suffix deleted.
It is
evaluated only for inference rules.
.TP
.B $@
The \fB$@\fR macro stands for
the full target name of the current target.
It is evaluated
only for explicitly named dependencies.
.TP
.B $<
The \fB$<\fR macro is only evaluated for inference rules or
the .DEFAULT rule.
It is
the module which is out-of-date with respect to the target (that is,
the manufactured dependent file name).
Thus, in the \fB.c.o\fR rule, the \fB$<\fR macro would evaluate to
the \fB.c\fR file.
An example for making
optimized \fB.o\fR files from \fB.c\fR files is:
.EX
\&.c.o:
cc \-c \-O $\(**.c
.EE
or:
.EX
\&.c.o:
cc \-c \-O $<
.EE
.TP 15
\fB$?\fR
The \fB$?\fR macro is evaluated when explicit rules from the makefile
are evaluated.
It is
the list of prerequisites that are out of date with respect to
the target;
essentially, those modules which must be rebuilt.
.TP
\fB$%\fR
The \fB$%\fR macro is only evaluated when the target is an
archive library member of the form \fBlib(file.o)\fR.
In this case,
\fB$@\fR evaluates to \fBlib\fR and \fB$%\fR evaluates to the
library member, \fBfile.o\fR.
.PP
Four of the five macros can have alternative forms.
When an upper case \fBD\fR or \fBF\fR is appended to any of the four
macros, the meaning is changed to directory part for \fBD\fR
and file part for \fBF\fR.
Thus, \fB$(@D)\fR refers to the directory
part of the string \fB$@\fR.
If there is no directory part,
\&\fB./\fR is generated.
The only macro excluded from this
alternative form is \fB$?\fR.
The reasons for this are debatable.
.SS Suffixes
Certain names (for instance, those ending with \fB.o\fR)
have prerequisites such as \fB.c\fR, \fB.s\fR, which can be
inferred.
If no update commands for such a file appear in
.IR makefile ,
and if an inferable prerequisite
exists, that prerequisite is compiled to make the target.
In this case,
.PN make
has
inference rules
which allow building files from other files
by examining the suffixes and determining an
appropriate
inference rule
to use.
The current default inference rules
are:
.EX 0
\&.c \|.c~ \|.sh \|.sh~ \|.c.o \|.c~.o \|.c~.c \|.s.o \|.s~.o \|.y.o 
\|.y~.o \|.l.o \|.l~.o \|.y.c \|.y~.c \|.l.c \|.c.a \|.c~.a \|.s~.a \|.h~.h
.EE
.PP
The internal rules for 
.PN make
are contained in the source
file \fBrules.c\fR for the 
.PN make
program.  These rules can be locally modified.
To print out the rules compiled into 
.PN make
in a form suitable for recompilation,
the following command is used from 
.PN /bin/sh:
.EX
make \-fp \- 2>/dev/null </dev/null
.EE
.PP
The only peculiarity in this output is the
(null)
string which 
.MS printf 3s
prints when handed a null string.
.PP
A tilde in the above rules refers to an SCCS file.
Thus, the
rule \fB.c~.o\fR would transform an SCCS C source file into an
object file (\fB.o\fR).
Because the \fBs.\fR of the SCCS files is a prefix,
it is incompatible with the  
.PN make 
suffix point-of-view.
Hence,
the tilde is a way of changing any file reference into an SCCS
file reference.
.PP
A rule with only one suffix (that is, \fB.c:\fR) is the definition
of how to build \fIx\fR from \fIx\fR\fB.c\fR.
In effect, the other suffix is null.
This is useful for building targets
from only one source file (for
example, shell procedures, simple C programs).
.PP
Additional suffixes are given as the
dependency list for .SUFFIXES.
Order is significant; the first possible name for which both
a file and a rule exist is inferred as a prerequisite.
The default list is:
.EX
\&.SUFFIXES: .o .c .y .l .s
.EE
Here again, the above command for printing the internal rules 
display the list of suffixes implemented on the current machine.
Multiple suffix lists accumulate;
\&.SUFFIXES: with no dependencies
clears the list of suffixes.
.SS Inference Rules
The first example can be done more briefly.
.EX
pgm: a.o b.o
   cc a.o b.o \-o pgm
a.o b.o: incl.h
.EE
This is because 
.PN make
has a set of internal rules for building
files.
The user may add rules to this list by simply putting
them in the 
.I makefile.
.PP
Certain macros are used by the default inference rules
to permit the inclusion of optional matter in
any resulting commands.
For example, CFLAGS, LFLAGS, and YFLAGS
are used for compiler options to 
.MS cc 1 ,
.MS lex 1 ,
and
.MS yacc 1 ,
respectively.
Again, the previous method for examining
the current rules is recommended.
.PP
The inference of prerequisites can be controlled.
The rule to create a file with suffix
.B \&.o
from a file with suffix
.B \&.c
is specified as an entry with \fB.c.o:\fR as the 
target and no dependents.
Shell commands associated with the target define the
rule for making a \fB.o\fR file from a \fB.c\fR file.
Any target that has no slashes in it and starts with a dot
is identified as a rule and not a true target.
.SS Libraries
If a target or dependency name contains parentheses, it is
assumed to be an archive library, the string within parentheses
referring to a member within the library.
Thus \fBlib(file.o)\fR and \fB$(\s-1LIB\s+1)(file.o)\fR both refer to
an archive library which contains \fBfile.o\fR. (This assumes
the LIB
macro has been previously defined.)\ 
The expression \fB$(\s-1LIB\s+1)(file1.o file2.o)\fR is not legal.
Rules pertaining to archive libraries have the form
.BI \&. \s-1XX\s+1 \&.a
where the
.I XX
is the suffix from which the archive member
is to be made.
An unfortunate byproduct of the current implementation
requires the
.I XX
to be different from the suffix of the archive
member.
Thus, one
cannot have \fBlib(file.o)\fR depend upon \fBfile.o\fR explicitly.
The most common use of the archive interface follows.
Here, we assume the source files are all C type source:
.EX
lib: lib(file1.o) lib(file2.o) lib(file3.o)
   @echo lib is now up-to-date
\&.c.a:
   $(CC) \-c $(CFLAGS1) $<
   ar rv $@ $*.o
   rm \-f $*.o
.EE
In fact, the \fB.c.a\fR rule listed above is built into 
.PN make
and
is unnecessary in this example.
A more interesting, but more limited example of an archive library
maintenance construction follows:
.EX
lib: lib(file1.o) lib(file2.o) lib(file3.o)
   $(CC) \-c $(CFLAGS) $(?:.o=.c)
   ar rv lib $?
   rm $?   
   @echo lib is now up-to-date
\&.c.a:;
.EE
Here the substitution mode of the macro expansions is used.
The \fB$?\fR
list is defined to be the set of object file names (inside \fBlib\fR) whose C
source files are out-of-date.  The substitution mode
translates the \fB.o\fR to \fB.c\fR.
(Unfortunately, one cannot as yet transform
to \fB.c~\fR; however, this may become possible in the future.)\ 
Note also, the disabling of the
\&\fB.c.a:\fR rule, which would have
created each object file, one by one.
This particular construct speeds up 
archive library maintenance considerably.
This type of construct becomes very cumbersome if the archive library
contains a mix of assembly programs and C programs.
.SH Restrictions
Some commands return non-zero status inappropriately;
use
.B \-i
to overcome the difficulty.
File names with the characters
.B "= : @"
do not work.
Commands that are directly executed by the shell, notably cd(1),
are ineffectual across new-lines in
.PN make .
The syntax \fB(lib(file1.o file2.o file3.o)\fR is illegal.
You cannot build \fBlib(file.o)\fR from \fBfile.o\fR.
The macro \fB$(a:.o=.c~)\fR does not work.
.SH Files
[Mm]akefile and s\fB.\fR[Mm]akefile
.SH See Also
cc(1), cd(1), lex(1), sh(1), yacc(1), s5make(1)