make, s5make - maintain, update, and regenerate groups of programs
Syntaxmake [ -f makefile ] [ options ] [ names ]
s5make [ -f makefile ] [ options ] [ names ]
This is the SYSTEM V version of the command with some Berkeley compati‐
Options-b Compatibility mode for old makefiles.
-d Debug mode. Displays detailed information on files and
-e Causes environment variables to override assignments
-f makefile Uses the specified description file name. A file name
of - denotes the standard input. The contents of the
file specified as makefile override the built-in rules.
-i Ignores error codes returned by invoked commands. This
mode is entered if the special target name .IGNORE
appears in the description file.
-k Stops work on the current entry, but continues on other
branches that do not depend on that entry.
-m Displays a memory map showing text, data, and the stack.
Does not operate on systems without the system call.
-n No execute mode. Displays commands, but does not exe‐
cute them. Even lines beginning with an at sign (@) are
-p Displays the complete set of macro definitions and tar‐
-q Question mode. Returns a zero or nonzero status code
depending on whether the target file is or is not up to
-r Does not use the built-in rules.
-s Silent mode. Suppresses the display of command lines
before executing. This mode is also entered if the spe‐
cial target name .SILENT appears in the description
-S Abandon work on the current entry if it fails; the oppo‐
site of the -k option. If both options are specified,
the last one specified on the command line is used.
-t Touches target files (causing them to be up to date)
rather than issuing usual commands.
Some commands return non-zero status inappropriately; use -i to over‐
come the difficulty. File names with the characters = : @ do not work.
Commands that are directly executed by the shell, notably cd(1), are
ineffectual across new-lines in 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.
If a makefile contains a dependency on a nonexistent file, instead of
always executing the rule, the current time is used for comparison.
This can cause trouble when using across an NFS environment if the time
on the file server is later than the time on the client.
The command treats two dollar signs ( ) as the end of a file name in a
dependency list, not as a single dollar sign ( ).
The command is unable to create a rule that will travel to a SCCS
directory, extract a file from SCCS, then copy it down to the current
If the command is executed in the current directory, but no makefile
exists, the command does not travel to the SCCS directory and search
for a version of the makefile to from SCCS and copy down to the current
working directory such that the original command may continue execu‐
The command does not rebuild a source file if the source file is a new
link to an old file.
.DEFAULT If a file must be made but there are no explicit com‐
mands or relevant built-in rules, the commands associ‐
ated with the name .DEFAULT are used if it exists.
.PRECIOUS Dependents of this target are not removed when quit or
interrupt is hit.
.SILENT Same effect as the -s option.
.IGNORE Same effect as the -i option.
.SUFFIXES Dependencies of the .SUFFIXES special target are added
to the table of known suffixes.
The 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 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 (equence. Everything printed by (except the ini‐
tial tab) is passed directly to the shell. For example:
These entries produce the following:
This output is exactly the same as what would have been produced by the
Number sign (#) and new-line surround comments.
The following makefile says that pgm depends on two files and and that
they in turn depend on their corresponding source files and and a com‐
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, ignores an error. A line is printed when it is executed
unless the -s option is present, or the entry .SILENT: 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 discussion
of the MAKEFLAGS macro under Environment). The -t (touch) option
updates the modified date of a file without executing any commands.
Commands returning nonzero status normally terminate If the -i option
is present, or the entry .IGNORE: 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 to run without errors. The difference between the old version of
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 assumed, if no command was specified 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 .PRECIOUS.
The environment is always read by All variables are assumed to be macro
definitions and processed as such. The -e option causes the environ‐
ment to override the macro assignments in a makefile.
The command operates in three compatibility modes. The type of mode is
determined by value of the PROG_ENV environment variable and by the way
that is executed. The PROG_ENV variable has three valid values:
In BSD mode, executes with Berkeley compatibility. This means that is
always used as the command interpreter regardless of the value of
SHELL, and the commands are echoed to standard out without a prefixed
In POSIX mode, executes with POSIX compatibility, such that the SHELL
environment variable is always ignored, SHELL is always overridden by
MAKESHELL, the shell is always used to execute commands, and commands
are echoed to standard out with a prefixed <tab>.
SYSTEM_FIVE mode causes to run with SYSTEM V compatibility such that
SHELL is used to execute commands and commands are echoed to standard
out with a prefixed <tab>.
For all modes, SHELL has a default value of When is executed with the
command name it always executes in SYSTEM_FIVE mode and ignores the
environment variable PROG_ENV.
The MAKEFLAGS environment variable is processed by as containing any
legal input option (except -f, -p, and -d defined for the command
line. Further, upon invocation, 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 -n recursively on a whole soft‐
ware 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 software
project without actually doing anything.
Macros can be defined in four different ways. Some macros are defined
by default by internally. All environment variables are assumed to be
macro definitions and macros can be defined in the makefile as well as
on the command line. By default, the internal default macros are over‐
ridden by environment variables, macros defined in the makefile over‐
ride environment variables and macros defined on the command line over‐
ride 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. 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 : subst1 = subst2 is a substitute sequence. If it is speci‐
fied, all non-overlapping occurrences of subst1 in the named macro are
replaced by subst2. The occurrence of subst1 must be a suffix at the
end of the word string1. 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 Libraries.
The MACHINE macro is defined by to allow for machine independent make‐
files. The legal values are: vax or mips.
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 cur‐
rent dependent with the suffix deleted. It is evaluated
only for inference rules.
$@ The $@ macro stands for the full target name of the cur‐
rent target. It is evaluated only for explicitly named
$< 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 manufac‐
tured dependent file name). Thus, in the .c.o rule, the
$< macro would evaluate to the .c file. An example for
making optimized .o files from .c files is:
cc -c -O $∗.c
cc -c -O $<
$? The $? 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; essen‐
tially, those modules which must be rebuilt.
$% The $% macro is only evaluated when the target is an ar‐
chive library member of the form lib(file.o). In this
case, $@ evaluates to lib and $% evaluates to the
library member, file.o.
All of the macros can have alternative forms. When an upper case D or
F is appended to any of the 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.
Certain names (for instance, those ending with .o) have prerequisites
such as .c, .s, which 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, has
inference rules which allow building files from other files by examin‐
ing 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 are contained in the source file rules.c for the
program. These rules can be locally modified. To print out the rules
compiled into in a form suitable for recompilation, the following com‐
mand is used from
make-fp - 2>/dev/null </dev/null
The only peculiarity in this output is the (null) string which prints
when handed a null string.
A tilde in the above rules refers to an SCCS file. Thus, the rule
.c~.o 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 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, .c:) is the 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 pro‐
cedures, simple 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
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 has a set of internal rules for building files. The
user may add rules to this list by simply putting them in the makefile.
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 and respec‐
tively. Again, the previous method for examining the current rules is
The inference of prerequisites can be controlled. The rule to create a
file with suffix .o from a file with suffix .c is specified as an entry
with .c.o: as the target and no dependents. Shell commands associated
with the target define the rule for making a .o file from a .c file.
Any target that has no slashes in it and starts with a dot is identi‐
fied as a rule and not a true target.
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.a 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, we assume 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
$(CC) -c $(CFLAGS1) $<
ar rv $@ $*.o
rm -f $*.o
In fact, the .c.a rule listed above is built into 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 $?
@echo lib is now up-to-date
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 .o
to .c. (Unfortunately, one cannot as yet transform to .c~; however,
this may become possible in the future.) Note also, the disabling of
the .c.a: rule, which would have created each object file, one by one.
This particular construct speeds up archive library maintenance consid‐
erably. This type of construct becomes very cumbersome if the archive
library contains a mix of assembly programs and C programs.
See Alsocc(1), cd(1), lex(1), sh(1), yacc(1), s5make(1)make(1)