make(1u)make(1u)NAMEmake - Maintains, updates, and regenerates groups of programs.
SYNOPSISmake [-f makefile] [options] [names]
OPTIONS
Compatibility mode for old makefiles. Debug mode. Displays detailed
information on files and times examined. Causes environment variables
to override assignments within makefiles. Uses the specified descrip‐
tion file name. A file name of - denotes the standard input. The con‐
tents of the file specified as makefile override the built-in rules.
Ignores error codes returned by invoked commands. This mode is entered
if the special target name .IGNORE appears in the description file.
Stops work on the current entry, but continues on other branches that
do not depend on that entry. No execute mode. Displays commands, but
does not execute them. Even lines beginning with an at sign (@) are
displayed. Displays the complete set of macro definitions and target
descriptions. Question mode. Returns a zero or nonzero status code
depending on whether the target file is or is not up to date. Does not
use the built-in rules. Silent mode. Suppresses the display of com‐
mand lines before executing. This mode is also entered if the special
target name .SILENT appears in the description file. Abandons work on
the current entry if it fails; the opposite of the -k option. If both
options are specified, the last one specified on the command line is
used. Touches target files (causing them to be up to date) rather than
issuing the usual commands.
DESCRIPTION
This make command is one of several versions available. See the SEE
ALSO section for references to information about other versions of the
command. By default, the make(1) command is invoked if you type the
command name with no path. To access the make(1u) version described in
this reference page, use the following command path:
/usr/opt/ultrix/usr/bin/make
The make program is designed to simplify the maintenance of other pro‐
grams. This is the SYSTEM V version of the make command with some
Berkeley compatibility added.
The make program executes commands in makefile to update one or more
target names. The name argument is typically a program. If no -f
option is present, makefile, Makefile, s.makefile, and s.Makefile are
tried in order. If makefile is -, the standard input is taken. You can
specify more than one -f makefile argument.
The make program updates a target only if its dependents are newer than
the target. All prerequisite files of a target are added recursively
to the list of targets. Missing files are deemed to be out of date.
The makefile argument contains a sequence of entries that specify
dependencies. The first line of an entry is a blank-separated, non-
null list of targets, then a colon (:), then a (possibly null) list of
prerequisite files or dependencies. Text following a semicolon (;) and
all following lines that begin with a tab are shell commands to be exe‐
cuted to update the target. The first line that does not begin with a
tab or number sign (#) begins a new dependency or macro definition.
Shell commands can be continued across lines with the backslash fol‐
lowed by a new-line (RET) sequence. Everything printed by make (except
the initial tab) is passed directly to the shell. For example: echo a\
b
These entries produce the following:
ab
This output is exactly the same as what would have been produced by the
shell.
The Number sign (#) and new-line surround comments.
The following makefile says that pgm depends on two files a.o and b.o,
and that they in turn depend on their corresponding source files (a.c
and b.c) and a common file <incl.h>:
pgm: a.o b.o
cc a.o b.o -o pgm a.o: incl.h a.c
cc -c a.c b.o: incl.h b.c
cc -c b.c
Command lines are executed one at a time, each by its own shell. The
first one or two characters in a command can be the following: -, @,
-@, or @-. If @ is present, printing of the command is suppressed. If -
is present, make ignores an error. A line is printed when it is exe‐
cuted unless the -s option is present, or the entry is in makefile, or
unless the initial character sequence contains a @. The -n option
specifies printing without execution. However, if the command line has
the string $(MAKE) in it, the line is always executed. (See the dis‐
cussion of the MAKEFLAGS macro under the Environment section). The -t
(touch) option updates the modified date of a file without executing
any commands.
Commands returning nonzero status normally terminate make. If the -i
option is present, or the entry appears in makefile, or the initial
character sequence of the command contains -, the error is ignored. If
the -k option is present, work stops on the current entry, but contin‐
ues on other branches that do not depend on that entry.
The -b option allows old makefiles (those written for the old version
of make) to run without errors. The difference between the old version
of make and this version is that this version requires all dependency
lines to have a (possibly null or implicit) command associated with
them. The previous version of make assumed, if no command was speci‐
fied explicitly, that the command was null.
Interrupt and quit cause the target to be deleted unless the target is
a dependent of the special name
Environment
The environment is always read by make. All variables are assumed to be
macro definitions and processed as such. The -e option causes the envi‐
ronment to override the macro assignments in a makefile.
The make command operates in three compatibility modes. The type of
mode is determined by the value of the PROG_ENV environment variable
and by the way that make is executed. The PROG_ENV variable has two
valid values: BSD POSIX
In BSD mode, make executes with Berkeley compatibility. This means
that /bin/sh is always used as the command interpreter regardless of
the value of SHELL, and the commands are echoed to standard out without
a prefixed <tab>.
In POSIX mode, make executes with POSIX compatibility, such that the
SHELL environment variable is always ignored, SHELL is always overrid‐
den by MAKESHELL, the shell is always used to execute commands, and
commands are echoed to standard out with a prefixed <tab>.
The MAKEFLAGS environment variable is processed by make as containing
any legal input option (except -f, -p, and -d) defined for the command
line. Further, upon invocation, 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 -n option is used, the command $(MAKE) is exe‐
cuted anyway. Hence, one can perform a make-n recursively on a whole
software system to see what would have been executed. This is because
the -n is put in MAKEFLAGS and passed to further invocations of
$(MAKE). This is one way of debugging all of the makefiles for a soft‐
ware project without actually doing anything.
Macros
Macros can be defined in four different ways. Some macros are defined
by default by make internally. All environment variables are assumed
to be macro definitions and macros can be defined in the makefile as
well as on the 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 com‐
mand line override macros defined in the makefile. The -e option
changes this such that environment variables override macros defined in
the makefile.
Entries of the form string1 = string2 are macro definitions. The
string2 is defined as all characters up to a comment character or an
unescaped new-line. Subsequent appearances of $( string1 [: subst1 = [
subst2 ]] ) are replaced by string2. The parentheses are optional if a
single character macro name is used and there is no substitute
sequence. The optional : subst1i = subst2 is a substitute sequence. If
it is specified, all non-overlapping occurrences of subst1 in the named
macro are replaced by subst2. The occurrence of subst1 must be a suf‐
fix at the end of the word string1. Strings (for the purposes of this
type of substitution) are delimited by blanks, tabs, new-line charac‐
ters, and beginnings of lines. An example of the use of the substitute
sequence is shown in the Libraries section.
The MACHINE macro is defined by make to allow for machine independent
makefiles. The default string for MACHINE is “vax”, “mips”, or
“alpha”, according to which machine the application is running on. You
can redefine MACHINE to one of the other strings for cross development
work.
Internal Macros
There are five internally maintained macros which are useful for writ‐
ing rules for building targets. The macro $* stands for the file name
part of the current dependent with the suffix deleted. It is evaluated
only for inference rules. The $@ macro stands for the full target name
of the current target. It is evaluated only for explicitly named depen‐
dencies. The $< 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 rule, the $< macro would evaluate to the file. Here are two exam‐
ples for making optimized files from files:
.c.o: cc -c -O $*.c
.c.o: cc -c -O $< The $? macro is evaluated when explicit rules
from the makefile are evaluated. It is the list of prerequi‐
sites that are out of date with respect to the target; essen‐
tially, those modules which must be rebuilt. The $% macro is
only evaluated when the target is an archive library member of
the form lib(file.o). In this case, $@ evaluates to lib and $%
evaluates to the library member, file.o.
Four of the five macros can have alternative forms. When an upper case
D or F is appended to any of the four macros, the meaning is changed to
directory part for D and file part for F. Thus, $(@D) refers to the
directory part of the string $@. If there is no directory part, is
generated. The only macro excluded from this alternative form is $?.
The reasons for this are debatable.
Special Names
If a file must be made but there are no explicit commands or relevant
built-in rules, the commands associated with the name .DEFAULT are used
if it exists. Dependents of this target are not removed when quit or
interrupt is hit. Same effect as the -s option. Same effect as the -i
option. Dependencies of the .SUFFIXES special target are added to the
table of known suffixes.
Suffixes
Certain names (for instance, those ending with have prerequisites such
as can be inferred. If no update commands for such a file appear in
makefile, and if an inferable prerequisite exists, that prerequisite is
compiled to make the target. In this case, make has inference rules
that allow building files from other files by examining the suffixes
and determining an appropriate inference rule to use. The current
default inference rules are:
.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
The internal rules for make are contained in the source file rules.c
for the make program. These rules can be locally modified. To print
out the rules compiled into make in a form suitable for recompilation,
the following command is used from /bin/sh: make-fp - 2>/dev/null
</dev/null
The only peculiarity in this output is the (null) string which
printf(3) prints when handed a null string.
A tilde in the above rules refers to an SCCS file. Thus, the rule
would transform an SCCS C source file into an object file (.o).
Because the s. of the SCCS files is a prefix, it is incompatible with
the make suffix point-of-view. Hence, the tilde is a way of changing
any file reference into an SCCS file reference.
A rule with only one suffix (that is, definition of how to build x from
x.c. In effect, the other suffix is null. This is useful for building
targets from only one source file (for example, shell procedures, sim‐
ple C programs).
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:
.SUFFIXES: .o .c .y .l .s
Here again, the above command for printing the internal rules display
the list of suffixes implemented on the current machine. Multiple suf‐
fix lists accumulate; .SUFFIXES: with no dependencies clears the list
of suffixes.
Inference Rules
The first example can be done more briefly:
pgm: a.o b.o
cc a.o b.o -o pgm a.o b.o: incl.h
This is because make has a set of internal rules for building files.
The user may add rules to this list by simply putting them in the make‐
file.
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 flags to cc(1),
lex(1), and yacc(1), respectively. Again, the previous method for exam‐
ining the current rules is recommended.
The inference of prerequisites can be controlled. The rule to create a
file with suffix from a file with suffix is specified as an entry with
as the target and no dependents. Shell commands associated with the
target define the rule for making a file from a file. Any target that
has no slashes in it and starts with a dot is identified as a rule and
not a true target.
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 lib(file.o) and $(LIB)(file.o) both
refer to an archive library which contains file.o. (This assumes the
LIB macro has been previously defined.) The expression $(LIB)(file1.o
file2.o) is not legal. Rules pertaining to archive libraries have the
form XX where the XX is the suffix from which the archive member is to
be made. An unfortunate byproduct of the current implementation
requires the XX to be different from the suffix of the archive member.
Thus, one cannot have lib(file.o) depend upon file.o explicitly. The
most common use of the archive interface follows. Here, it is assumed
that the source files are all C type source:
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
In fact, the rule listed above is built into make and is unnecessary in
this example. A more interesting, but more limited example of an ar‐
chive library maintenance construction follows:
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:;
Here the substitution mode of the macro expansions is used. The $?
list is defined to be the set of object file names (inside lib) whose C
source files are out-of-date. The substitution mode translates the to
one cannot transform to of the 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.
RESTRICTIONS
Some commands return non-zero status inappropriately. Use -i to over‐
come the difficulty. File names with the characters =, :, or @ do not
work. Commands that are directly executed by the shell, notably cd(1),
are ineffectual across new-lines in make. The syntax (lib(file1.o
file2.o file3.o) is illegal. You cannot build lib(file.o) from file.o.
The macro $(a:.o=.c~) does not work.
FILESSEE ALSOcc(1), cd(1), lex(1), make(1), make(1p), sh(1), yacc(1)make(1u)
