---

   make.1p    ( 1 )

---

Обоснование (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.