The make utility described in this volume of POSIX.1‐2017 is
intended to provide the means for changing portable source code
into executables that can be run on an POSIX.1‐2008-conforming
system. It reflects the most common features present in System V
and BSD makes.
Historically, the make utility has been an especially fertile
ground for vendor and research organization-specific syntax
modifications and extensions. Examples include:
* Syntax supporting parallel execution (such as from various
multi-processor vendors, GNU, and others)
* Additional ``operators'' separating targets and their
prerequisites (System V, BSD, and others)
* Specifying that command lines containing the strings
"${MAKE}" and "$(MAKE)" are executed when the -n option is
specified (GNU and System V)
* Modifications of the meaning of internal macros when
referencing libraries (BSD and others)
* Using a single instance of the shell for all of the command
lines of the target (BSD and others)
* Allowing <space> characters as well as <tab> characters to
delimit command lines (BSD)
* Adding C preprocessor-style ``include'' and ``ifdef''
constructs (System V, GNU, BSD, and others)
* Remote execution of command lines (Sprite and others)
* Specifying additional special targets (BSD, System V, and
most others)
* Specifying an alternate shell to use to process commands.
Additionally, many vendors and research organizations have
rethought the basic concepts of make, creating vastly extended,
as well as completely new, syntaxes. Each of these versions of
make fulfills the needs of a different community of users; it is
unreasonable for this volume of POSIX.1‐2017 to require behavior
that would be incompatible (and probably inferior) to historical
practice for such a community.
In similar circumstances, when the industry has enough
sufficiently incompatible formats as to make them irreconcilable,
this volume of POSIX.1‐2017 has followed one or both of two
courses of action. Commands have been renamed (cksum, echo, and
pax) and/or command line options have been provided to select the
desired behavior (grep, od, and pax).
Because the syntax specified for the make utility is, by and
large, a subset of the syntaxes accepted by almost all versions
of make, it was decided that it would be counter-productive to
change the name. And since the makefile itself is a basic unit
of portability, it would not be completely effective to reserve a
new option letter, such as make -P, to achieve the portable
behavior. Therefore, the special target .POSIX was added to the
makefile, allowing users to specify ``standard'' behavior. This
special target does not preclude extensions in the make utility,
nor does it preclude such extensions being used by the makefile
specifying the target; it does, however, preclude any extensions
from being applied that could alter the behavior of previously
valid syntax; such extensions must be controlled via command line
options or new special targets. It is incumbent upon portable
makefiles to specify the .POSIX special target in order to
guarantee that they are not affected by local extensions.
The portable version of make described in this reference page is
not intended to be the state-of-the-art software generation tool
and, as such, some newer and more leading-edge features have not
been included. An attempt has been made to describe the portable
makefile in a manner that does not preclude such extensions as
long as they do not disturb the portable behavior described here.
When the -n option is specified, it is always added to MAKEFLAGS.
This allows a recursive make -n target to be used to see all of
the action that would be taken to update target.
The definition of MAKEFLAGS allows both the System V letter
string and the BSD command line formats. The two formats are
sufficiently different to allow implementations to support both
without ambiguity.
Early proposals stated that an ``unquoted'' <number-sign> was
treated as the start of a comment. The make utility does not pay
any attention to quotes. A <number-sign> starts a comment
regardless of its surroundings.
The text about ``other implementation-defined pathnames may also
be tried'' in addition to ./makefile and ./Makefile is to allow
such extensions as SCCS/s.Makefile and other variations. It was
made an implementation-defined requirement (as opposed to
unspecified behavior) to highlight surprising implementations
that might select something unexpected like /etc/Makefile. XSI-
conformant systems also try ./s.makefile, SCCS/s.makefile,
./s.Makefile, and SCCS/s.Makefile.
Early proposals contained the macro NPROC as a means of
specifying that make should use n processes to do the work
required. While this feature is a valuable extension for many
systems, it is not common usage and could require other non-
trivial extensions to makefile syntax. This extension is not
required by this volume of POSIX.1‐2017, but could be provided as
a compatible extension. The macro PARALLEL is used by some
historical systems with essentially the same meaning (but without
using a name that is a common system limit value). It is
suggested that implementors recognize the existing use of NPROC
and/or PARALLEL as extensions to make.
The default rules are based on System V. The default CC= value is
c99 instead of cc because this volume of POSIX.1‐2017 does not
standardize the utility named cc. Thus, every conforming
application would be required to define CC=c99 to expect to run.
There is no advantage conferred by the hope that the makefile
might hit the ``preferred'' compiler because this cannot be
guaranteed to work. Also, since the portable makescript can only
use the c99 options, no advantage is conferred in terms of what
the script can do. It is a quality-of-implementation issue as to
whether c99 is as valuable as cc.
The -d option to make is frequently used to produce debugging
information, but is too implementation-defined to add to this
volume of POSIX.1‐2017.
The -p option is not passed in MAKEFLAGS on most historical
implementations and to change this would cause many
implementations to break without sufficiently increased
portability.
Commands that begin with a <plus-sign> ('+') are executed even if
the -n option is present. Based on the GNU version of make, the
behavior of -n when the <plus-sign> prefix is encountered has
been extended to apply to -q and -t as well. However, the System
V convention of forcing command execution with -n when the
command line of a target contains either of the strings "$(MAKE)"
or "${MAKE}" has not been adopted. This functionality appeared in
early proposals, but the danger of this approach was pointed out
with the following example of a portion of a makefile:
subdir:
cd subdir; rm all_the_files; $(MAKE)
The loss of the System V behavior in this case is well-balanced
by the safety afforded to other makefiles that were not aware of
this situation. In any event, the command line <plus-sign> prefix
can provide the desired functionality.
The double <colon> in the target rule format is supported in BSD
systems to allow more than one target line containing the same
target name to have commands associated with it. Since this is
not functionality described in the SVID or XPG3 it has been
allowed as an extension, but not mandated.
The default rules are provided with text specifying that the
built-in rules shall be the same as if the listed set were used.
The intent is that implementations should be able to use the
rules without change, but will be allowed to alter them in ways
that do not affect the primary behavior.
One point of discussion was whether to drop the default rules
list from this volume of POSIX.1‐2017. They provide convenience,
but do not enhance portability of applications. The prime benefit
is in portability of users who wish to type make command and have
the command build from a command.c file.
The historical MAKESHELL feature, and related features provided
by other make implementations, were omitted. In some
implementations it is used to let a user override the shell to be
used to run make commands. This was confusing; for a portable
make, the shell should be chosen by the makefile writer. Further,
a makefile writer cannot require an alternate shell to be used
and still consider the makefile portable. While it would be
possible to standardize a mechanism for specifying an alternate
shell, existing implementations do not agree on such a mechanism,
and makefile writers can already invoke an alternate shell by
specifying the shell name in the rule for a target; for example:
python -c "foo"
The make utilities in most historical implementations process the
prerequisites of a target in left-to-right order, and the
makefile format requires this. It supports the standard idiom
used in many makefiles that produce yacc programs; for example:
foo: y.tab.o lex.o main.o
$(CC) $(CFLAGS) -o $@ t.tab.o lex.o main.o
In this example, if make chose any arbitrary order, the lex.o
might not be made with the correct y.tab.h. Although there may
be better ways to express this relationship, it is widely used
historically. Implementations that desire to update prerequisites
in parallel should require an explicit extension to make or the
makefile format to accomplish it, as described previously.
The algorithm for determining a new entry for target rules is
partially unspecified. Some historical makes allow comment lines
(including blank and empty lines) within the collection of
commands marked by leading <tab> characters. A conforming
makefile must ensure that each command starts with a <tab>, but
implementations are free to ignore comments without triggering
the start of a new entry.
The ASYNCHRONOUS EVENTS section includes having SIGTERM and
SIGHUP, along with the more traditional SIGINT and SIGQUIT,
remove the current target unless directed not to do so. SIGTERM
and SIGHUP were added to parallel other utilities that have
historically cleaned up their work as a result of these signals.
When make receives any signal other than SIGQUIT, it is required
to resend itself the signal it received so that it exits with a
status that reflects the signal. The results from SIGQUIT are
partially unspecified because, on systems that create core files
upon receipt of SIGQUIT, the core from make would conflict with a
core file from the command that was running when the SIGQUIT
arrived. The main concern was to prevent damaged files from
appearing up-to-date when make is rerun.
The .PRECIOUS special target was extended to affect all targets
globally (by specifying no prerequisites). The .IGNORE and
.SILENT special targets were extended to allow prerequisites; it
was judged to be more useful in some cases to be able to turn off
errors or echoing for a list of targets than for the entire
makefile. These extensions to make in System V were made to match
historical practice from the BSD make.
Macros are not exported to the environment of commands to be run.
This was never the case in any historical make and would have
serious consequences. The environment is the same as the
environment to make except that MAKEFLAGS and macros defined on
the make command line are added, and except that macros defined
by the MAKEFLAGS environment variable and macros defined in the
makefile(s) may update the value of an existing environment
variable (other than SHELL).
Some implementations do not use system() for all command lines,
as required by the portable makefile format; as a performance
enhancement, they select lines without shell metacharacters for
direct execution by execve(). There is no requirement that
system() be used specifically, but merely that the same results
be achieved. The metacharacters typically used to bypass the
direct execve() execution have been any of:
= | ^ ( ) ; & < > * ? [ ] : $ ` ' " \ \n
The default in some advanced versions of make is to group all the
command lines for a target and execute them using a single shell
invocation; the System V method is to pass each line individually
to a separate shell. The single-shell method has the advantages
in performance and the lack of a requirement for many continued
lines. However, converting to this newer method has caused
portability problems with many historical makefiles, so the
behavior with the POSIX makefile is specified to be the same as
that of System V. It is suggested that the special target
.ONESHELL be used as an implementation extension to achieve the
single-shell grouping for a target or group of targets.
Novice users of make have had difficulty with the historical need
to start commands with a <tab>. Since it is often difficult to
discern differences between <tab> and <space> characters on
terminals or printed listings, confusing bugs can arise. In early
proposals, an attempt was made to correct this problem by
allowing leading <blank> characters instead of <tab> characters.
However, implementors reported many makefiles that failed in
subtle ways following this change, and it is difficult to
implement a make that unambiguously can differentiate between
macro and command lines. There is extensive historical practice
of allowing leading <space> characters before macro definitions.
Forcing macro lines into column 1 would be a significant
backwards-compatibility problem for some makefiles. Therefore,
historical practice was restored.
There is substantial variation in the handling of include lines
by different implementations. However, there is enough
commonality for the standard to be able to specify a minimum set
of requirements that allow the feature to be used portably. Known
variations have been explicitly called out as unspecified
behavior in the description.
The System V dynamic dependency feature was not included. It
would support:
cat: $$@.c
that would expand to;
cat: cat.c
This feature exists only in the new version of System V make and,
while useful, is not in wide usage. This means that macros are
expanded twice for prerequisites: once at makefile parse time and
once at target update time.
Consideration was given to adding metarules to the POSIX make.
This would make %.o: %.c the same as .c.o:. This is quite useful
and available from some vendors, but it would cause too many
changes to this make to support. It would have introduced rule
chaining and new substitution rules. However, the rules for
target names have been set to reserve the '%' and '"' characters.
These are traditionally used to implement metarules and quoting
of target names, respectively. Implementors are strongly
encouraged to use these characters only for these purposes.
A request was made to extend the suffix delimiter character from
a <period> to any character. The metarules feature in newer makes
solves this problem in a more general way. This volume of
POSIX.1‐2017 is staying with the more conservative historical
definition.
The standard output format for the -p option is not described
because it is primarily a debugging option and because the format
is not generally useful to programs. In historical
implementations the output is not suitable for use in generating
makefiles. The -p format has been variable across historical
implementations. Therefore, the definition of -p was only to
provide a consistently named option for obtaining make script
debugging information.
Some historical implementations have not cleared the suffix list
with -r.
Implementations should be aware that some historical applications
have intermixed target_name and macro=value operands on the
command line, expecting that all of the macros are processed
before any of the targets are dealt with. Conforming applications
do not do this, but some backwards-compatibility support may be
warranted.
Empty inference rules are specified with a <semicolon> command
rather than omitting all commands, as described in an early
proposal. The latter case has no traditional meaning and is
reserved for implementation extensions, such as in GNU make.
Earlier versions of this standard defined comment lines only as
lines with '#' as the first character. Many places then talked
about comments, blank lines, and empty lines; but some places
inadvertently only mentioned comments when blank lines and empty
lines had also been accepted in all known implementations. The
standard now defines comment lines to be blank lines, empty
lines, and lines starting with a '#' character and explictily
lists cases where blank lines and empty lines are not acceptable.
On most historic systems, the make utility considered a target
with a prerequisite that had an identical timestamp as up-to-
date. The HP-UX implementation of make treated it as out-of-date.
The standard now allows either behavior, but implementations are
encouraged to follow the example set by HP-UX. This is
especially important on file systems where the timestamp
resolution is the minimum (1 second) required by the standard.
All implementations of make should make full use of the finest
timestamp resolution available on the file systems holding
targets and prerequisites to ensure that targets are up-to-date
even for prerequisite files with timestamps that were updated
within the same second. However, if the timestamp resolutions of
the file systems containing a target and a prerequisite are
different, the timestamp with the more precise resolution should
be rounded down to the resolution of the less precise timestamp
for the comparison.
