PROLOG

This manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux.

NAME

make — maintain, update, and regenerate groups of programs (DEVELOPMENT)

SYNOPSIS

make [-einpqrst] [-f makefile]... [-k|-S] [macro=value...]


    [target_name...]

DESCRIPTION

The make utility shall update files that are derived from other files. A typical case is one where object files are derived from the corresponding source files. The make utility examines time relationships and shall update those derived files (called targets) that have modified times earlier than the modified times of the files (called prerequisites) from which they are derived. A description file (makefile) contains a description of the relationships between files, and the commands that need to be executed to update the targets to reflect changes in their prerequisites. Each specification, or rule, shall consist of a target, optional prerequisites, and optional commands to be executed when a prerequisite is newer than the target. There are two types of rule:

1.

Inference rules, which have one target name with at least one <period> ('.') and no <slash> ('/')

2.

Target rules, which can have more than one target name

In addition, make shall have a collection of built-in macros and inference rules that infer prerequisite relationships to simplify maintenance of programs.

To receive exactly the behavior described in this section, the user shall ensure that a portable makefile shall:

*

Include the special target .POSIX

*

Omit any special target reserved for implementations (a leading period followed by uppercase letters) that has not been specified by this section

The behavior of make is unspecified if either or both of these conditions are not met.

OPTIONS

The make utility shall conform to the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines, except for Guideline 9.

The following options shall be supported:

-e

Cause environment variables, including those with null values, to override macro assignments within makefiles.

-f makefile

Specify a different makefile. The argument makefile is a pathname of a description file, which is also referred to as the makefile. A pathname of '-' shall denote the standard input. There can be multiple instances of this option, and they shall be processed in the order specified. The effect of specifying the same option-argument more than once is unspecified.

-i

Ignore error codes returned by invoked commands. This mode is the same as if the special target .IGNORE were specified without prerequisites.

-k

Continue to update other targets that do not depend on the current target if a non-ignored error occurs while executing the commands to bring a target up-to-date.

-n

Write commands that would be executed on standard output, but do not execute them. However, lines with a <plus-sign> ('+') prefix shall be executed. In this mode, lines with an at-sign ('@') character prefix shall be written to standard output.

-p

Write to standard output the complete set of macro definitions and target descriptions. The output format is unspecified.

-q

Return a zero exit value if the target file is up-to-date; otherwise, return an exit value of 1. Targets shall not be updated if this option is specified. However, a makefile command line (associated with the targets) with a <plus-sign> ('+') prefix shall be executed.

-r

Clear the suffix list and do not use the built-in rules.

-S

Terminate make if an error occurs while executing the commands to bring a target up-to-date. This shall be the default and the opposite of -k.

-s

Do not write makefile command lines or touch messages (see -t) to standard output before executing. This mode shall be the same as if the special target .SILENT were specified without prerequisites.

-t

Update the modification time of each target as though a touch target had been executed. Targets that have prerequisites but no commands (see Target Rules), or that are already up-to-date, shall not be touched in this manner. Write messages to standard output for each target file indicating the name of the file and that it was touched. Normally, the makefile command lines associated with each target are not executed. However, a command line with a <plus-sign> ('+') prefix shall be executed.

Any options specified in the MAKEFLAGS environment variable shall be evaluated before any options specified on the make utility command line. If the -k and -S options are both specified on the make utility command line or by the MAKEFLAGS environment variable, the last option specified shall take precedence. If the -f or -p options appear in the MAKEFLAGS environment variable, the result is undefined.

OPERANDS

The following operands shall be supported:

target_name

Target names, as defined in the EXTENDED DESCRIPTION section. If no target is specified, while make is processing the makefiles, the first target that make encounters that is not a special target or an inference rule shall be used.

macro=value

Macro definitions, as defined in Macros.

If the target_name and macro=value operands are intermixed on the make utility command line, the results are unspecified.

STDIN

The standard input shall be used only if the makefile option-argument is '-'. See the INPUT FILES section.

INPUT FILES

The input file, otherwise known as the makefile, is a text file containing rules, macro definitions, include lines, and comments. See the EXTENDED DESCRIPTION section.

ENVIRONMENT VARIABLES

The following environment variables shall affect the execution of make:

LANG

Provide a default value for the internationalization variables that are unset or null. (See the Base Definitions volume of POSIX.1‐2017, Section 8.2, Internationalization Variables for the precedence of internationalization variables used to determine the values of locale categories.)

LC_ALL

If set to a non-empty string value, override the values of all the other internationalization variables.

LC_CTYPE

Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments and input files).

LC_MESSAGES

Determine the locale that should be used to affect the format and contents of diagnostic messages written to standard error.

MAKEFLAGS

This variable shall be interpreted as a character string representing a series of option characters to be used as the default options. The implementation shall accept both of the following formats (but need not accept them when intermixed):

NLSPATH

Determine the location of message catalogs for the processing of LC_MESSAGES.

PROJECTDIR

Provide a directory to be used to search for SCCS files not found in the current directory. In all of the following cases, the search for SCCS files is made in the directory SCCS in the identified directory. If the value of PROJECTDIR begins with a <slash>, it shall be considered an absolute pathname; otherwise, the value of PROJECTDIR is treated as a user name and that user's initial working directory shall be examined for a subdirectory src or source. If such a directory is found, it shall be used. Otherwise, the value is used as a relative pathname.

The value of the SHELL environment variable shall not be used as a macro and shall not be modified by defining the SHELL macro in a makefile or on the command line. All other environment variables, including those with null values, shall be used as macros, as defined in Macros.

ASYNCHRONOUS EVENTS

If not already ignored, make shall trap SIGHUP, SIGTERM, SIGINT, and SIGQUIT and remove the current target unless the target is a directory or the target is a prerequisite of the special target .PRECIOUS or unless one of the -n, -p, or -q options was specified. Any targets removed in this manner shall be reported in diagnostic messages of unspecified format, written to standard error. After this cleanup process, if any, make shall take the standard action for all other signals.

STDOUT

The make utility shall write all commands to be executed to standard output unless the -s option was specified, the command is prefixed with an at-sign, or the special target .SILENT has either the current target as a prerequisite or has no prerequisites. If make is invoked without any work needing to be done, it shall write a message to standard output indicating that no action was taken. If the -t option is present and a file is touched, make shall write to standard output a message of unspecified format indicating that the file was touched, including the filename of the file.

STDERR

The standard error shall be used only for diagnostic messages.

OUTPUT FILES

Files can be created when the -t option is present. Additional files can also be created by the utilities invoked by make.

EXTENDED DESCRIPTION

The make utility attempts to perform the actions required to ensure that the specified targets are up-to-date. A target shall be considered up-to-date if it exists and is newer than all of its dependencies, or if it has already been made up-to-date by the current invocation of make (regardless of the target's existence or age). A target may also be considered up-to-date if it exists, is the same age as one or more of its prerequisites, and is newer than the remaining prerequisites (if any). The make utility shall treat all prerequisites as targets themselves and recursively ensure that they are up-to-date, processing them in the order in which they appear in the rule. The make utility shall use the modification times of files to determine whether the corresponding targets are out-of-date.

To ensure that a target is up-to-date, make shall ensure that all of the prerequisites of a target are up-to-date, then check to see if the target itself is up-to-date. If the target is not up-to-date, the target shall be made up-to-date by executing the rule's commands (if any). If the target does not exist after the target has been successfully made up-to-date, the target shall be treated as being newer than any target for which it is a prerequisite.

If a target exists and there is neither a target rule nor an inference rule for the target, the target shall be considered up-to-date. It shall be an error if make attempts to ensure that a target is up-to-date but the target does not exist and there is neither a target rule nor an inference rule for the target.

target [target...]: [prerequisite...][;command]
[<tab>command
<tab>command
...]

line that does not begin with <tab>

string1 = [string2]

target:
<tab>command
[<tab>command]
...

line that does not begin with <tab> or #

rule: ;

SPECIAL TARGETS

.SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@

.SUFFIXES: .o .c .y .l .a .sh .f .c~ .y~ .l~ .sh~ .f~

MACROS

MAKE=make
AR=ar
ARFLAGS=-rv
YACC=yacc
YFLAGS=
LEX=lex
LFLAGS=
LDFLAGS=
CC=c99
CFLAGS=-O 1
FC=fort77
FFLAGS=-O 1
GET=get
GFLAGS=
SCCSFLAGS=
SCCSGETFLAGS=-s

SINGLE SUFFIX RULES

.c:


    $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<

.f:


    $(FC) $(FFLAGS) $(LDFLAGS) -o $@ $<

.sh:


    cp $< $@


    chmod a+x $@

.c~:


    $(GET) $(GFLAGS) -p $< > $*.c


    $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $*.c

.f~:


    $(GET) $(GFLAGS) -p $< > $*.f


    $(FC) $(FFLAGS) $(LDFLAGS) -o $@ $*.f

.sh~:


    $(GET) $(GFLAGS) -p $< > $*.sh


    cp $*.sh $@


    chmod a+x $@

DOUBLE SUFFIX RULES

.c.o:


    $(CC) $(CFLAGS) -c $<

.f.o:


    $(FC) $(FFLAGS) -c $<

.y.o:


    $(YACC) $(YFLAGS) $<


    $(CC) $(CFLAGS) -c y.tab.c


    rm -f y.tab.c


    mv y.tab.o $@

.l.o:


    $(LEX) $(LFLAGS) $<


    $(CC) $(CFLAGS) -c lex.yy.c


    rm -f lex.yy.c


    mv lex.yy.o $@

.y.c:


    $(YACC) $(YFLAGS) $<


    mv y.tab.c $@

.l.c:


    $(LEX) $(LFLAGS) $<


    mv lex.yy.c $@

.c~.o:


    $(GET) $(GFLAGS) -p $< > $*.c


    $(CC) $(CFLAGS) -c $*.c

.f~.o:


    $(GET) $(GFLAGS) -p $< > $*.f


    $(FC) $(FFLAGS) -c $*.f

.y~.o:


    $(GET) $(GFLAGS) -p $< > $*.y


    $(YACC) $(YFLAGS) $*.y


    $(CC) $(CFLAGS) -c y.tab.c


    rm -f y.tab.c


    mv y.tab.o $@

.l~.o:


    $(GET) $(GFLAGS) -p $< > $*.l


    $(LEX) $(LFLAGS) $*.l


    $(CC) $(CFLAGS) -c lex.yy.c


    rm -f lex.yy.c


    mv lex.yy.o $@

.y~.c:


    $(GET) $(GFLAGS) -p $< > $*.y


    $(YACC) $(YFLAGS) $*.y


    mv y.tab.c $@

.l~.c:


    $(GET) $(GFLAGS) -p $< > $*.l


    $(LEX) $(LFLAGS) $*.l


    mv lex.yy.c $@

.c.a:


    $(CC) -c $(CFLAGS) $<


    $(AR) $(ARFLAGS) $@ $*.o


    rm -f $*.o

.f.a:


    $(FC) -c $(FFLAGS) $<


    $(AR) $(ARFLAGS) $@ $*.o


    rm -f $*.o

EXIT STATUS

When the -q option is specified, the make utility shall exit with one of the following values:

 0

Successful completion.

 1

The target was not up-to-date.

>1

An error occurred.

When the -q option is not specified, the make utility shall exit with one of the following values:

 0

Successful completion.

>0

An error occurred.

CONSEQUENCES OF ERRORS

Default.

The following sections are informative.

APPLICATION USAGE

If there is a source file (such as ./source.c) and there are two SCCS files corresponding to it (./s.source.c and ./SCCS/s.source.c), on XSI-conformant systems make uses the SCCS file in the current directory. However, users are advised to use the underlying SCCS utilities (admin, delta, get, and so on) or the sccs utility for all source files in a given directory. If both forms are used for a given source file, future developers are very likely to be confused.

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 -k and -S options are both present so that the relationship between the command line, the MAKEFLAGS variable, and the makefile can be controlled precisely. If the k flag is passed in MAKEFLAGS and a command is of the form:

$(MAKE) -S foo

then the default behavior is restored for the child make.

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.

Because of widespread historical practice, interpreting a <number-sign> ('#') inside a variable as the start of a comment has the unfortunate side-effect of making it impossible to place a <number-sign> in a variable, thus forbidding something like:

CFLAGS = "-D COMMENT_CHAR='#'"

Many historical make utilities stop chaining together inference rules when an intermediate target is nonexistent. For example, it might be possible for a make to determine that both .y.c and .c.o could be used to convert a .y to a .o. Instead, in this case, make requires the use of a .y.o rule.

The best way to provide portable makefiles is to include all of the rules needed in the makefile itself. The rules provided use only features provided by other parts of this volume of POSIX.1‐2017. The default rules include rules for optional commands in this volume of POSIX.1‐2017. Only rules pertaining to commands that are provided are needed in an implementation's default set.

Macros used within other macros are evaluated when the new macro is used rather than when the new macro is defined. Therefore:

MACRO = value1
NEW   = $(MACRO)
MACRO = value2

target:


    echo $(NEW)

would produce value2 and not value1 since NEW was not expanded until it was needed in the echo command line.

Some historical applications have been known to intermix target_name and macro=name 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, although some backwards-compatibility support may be included in some implementations.

The following characters in filenames may give trouble: '=', ':', '`', single-quote, and '@'. In include filenames, pattern matching characters and '"' should also be avoided, as they may be treated as special by some implementations.

For inference rules, the description of $< and $? seem similar. However, an example shows the minor difference. In a makefile containing:

foo.o: foo.h

if foo.h is newer than foo.o, yet foo.c is older than foo.o, the built-in rule to make foo.o from foo.c is used, with $< equal to foo.c and $? equal to foo.h. If foo.c is also newer than foo.o, $< is equal to foo.c and $? is equal to foo.h foo.c.

As a consequence of the general rules for target updating, a useful special case is that if a target has no prerequisites and no commands, and the target of the rule is a nonexistent file, then make acts as if this target has been updated whenever its rule is run.

Note:

This implies that all targets depending on this one will always have their commands run.

Shell command sequences like make; cp original copy; make may have problems on filesystems where the timestamp resolution is the minimum (1 second) required by the standard and where make considers identical timestamps to be up-to-date. Conversely, rules like copy: original; cp -p original copy will result in redundant work on make implementations that consider identical timestamps to be out-of-date.

This standard does not specify precedence between macro definition and include directives. Thus, the behavior of:

include =foo.mk

is unspecified. To define a variable named include, either the white space before the <equal-sign> should be removed, or another macro should be used, as in:

INCLUDE_NAME = include
$(INCLUDE_NAME) =foo.mk

On the other hand, if the intent is to include a file which starts with an <equal-sign>, either the filename should be changed to ./=foo.mk, or the makefile should be written as:

INCLUDE_FILE = =foo.mk
include $(INCLUDE_FILE)

EXAMPLES

1.

The following command:

make

2.

The following command:

make junk

3.

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:

.POSIX:
pgm: a.o b.o


    c99 a.o b.o -o pgm
a.o: incl.h a.c


    c99 -c a.c
b.o: incl.h b.c


    c99 -c b.c

4.

An example for making optimized .o files from .c files is:

.c.o:


    c99 -c -O 1 $*.c

.c.o:


    c99 -c -O 1 $<

5.

The most common use of the archive interface follows. Here, it is assumed that the source files are all C-language source:

lib: lib(file1.o) lib(file2.o) lib(file3.o)


    @echo lib is now up-to-date

.c.o\
:

f=  bar baz\


    biz
a:


    echo ==$f==

/usr/include/stdio.h /usr/include/unistd.h foo.h

/usr/include /usr/include .

stdio.h unistd.h foo.h

6.

The contents of the built-in rules can be viewed by running:

make -p -f /dev/null 2>/dev/null

RATIONALE

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.

FUTURE DIRECTIONS

Some implementations of make include an export directive to add specified make variables to the environment. This may be considered for standardization in a future version.

A future version of this standard may require that macro expansions using the forms $(string1:[op]%[os]=[np][%][ns]) or ${string1:[op]%[os]=[np][%][ns]} are treated as pattern macro expansions.

SEE ALSO

Chapter 2, Shell Command Language, ar, c99, get, lex, sccs, sh, yacc

The Base Definitions volume of POSIX.1‐2017, Section 6.1, Portable Character Set, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines

The System Interfaces volume of POSIX.1‐2017, exec, system()

COPYRIGHT

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .