NAME

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

SYNOPSIS

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 XBD V1_chap12(7) , 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, 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 XBD 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):

• The characters are option letters without the leading <hyphen> characters or <blank> separation used on a make utility command line.
• The characters are formatted in a manner similar to a portion of the make utility command line: options are preceded by <hyphen> characters and <blank>-separated as described in XBD V1_chap12(7). The macro = value macro definition operands can also be included. The difference between the contents of MAKEFLAGS and the make utility command line is that the contents of the variable shall not be subjected to the word expansions (see wordexp(3)) associated with parsing the command line values.

NLSPATH

[ XSI] Determine the location of message catalogs for the processing of LC_MESSAGES.

PROJECTDIR

[ XSI]
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.

If PROJECTDIR is not set or has a null value, the search for SCCS files shall be made in the directory SCCS in the current directory.

The setting of PROJECTDIR affects all files listed in the remainder of this utility description for files with a component named SCCS.

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 is considered out-of-date if it is older than any of its prerequisites or if it does not exist. 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.

After make has ensured that all of the prerequisites of a target are up-to-date and if the target is out-of-date, the commands associated with the target entry shall be executed. If there are no commands listed for the target, the target shall be treated as up-to-date.

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

[XSI]
.SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@



[XSI]
.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
FC=fort77
FFLAGS=-O 1
[XSI]
GET=get
GFLAGS=
SCCSFLAGS=
SCCSGETFLAGS=-s



SINGLE SUFFIX RULES

.c:
    $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<


.f:
    $(FC) $(FFLAGS) $(LDFLAGS) -o $@ $<


.sh:
    cp $< $@
    chmod a+x $@


[XSI]
.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 $@


[XSI]
.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(1), delta(1), get(1), and so on) or the sccs(1) 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-2008. The default rules include rules for optional commands in this volume of POSIX.1-2008. 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(1) 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.

EXAMPLES

1. The following command:

   make

   makes the first target found in the makefile.

2. The following command:

   make junk

   makes the target 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:

   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 $*.c

   or:

   .c.o:
       c99 -c -O $<

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

   The .c.a rule is used to make file1.o, file2.o, and file3.o and insert them into lib.

   The treatment of escaped <newline> characters throughout the makefile is historical practice. For example, the inference rule:

   .c.o\
   :

   works, and the macro:

   f=  bar baz\
       biz
   a:
       echo ==$f==

   echoes "==bar baz biz==".

   If $? were:

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

   then $(?D) would be:

   /usr/include /usr/include .

   and $(?F) would be:

   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-2008 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 make s.

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)

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-2008 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-2008 has followed one or both of two courses of action. Commands have been renamed ( cksum(1), echo(1), and pax(1)) and/or command line options have been provided to select the desired behavior ( grep(1), od(1), and pax(1)).

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-2008, 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(1) instead of cc because this volume of POSIX.1-2008 does not standardize the utility named cc. Thus, every conforming application would be required to define CC= c99(1) 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(1) options, no advantage is conferred in terms of what the script can do. It is a quality-of-implementation issue as to whether c99(1) 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-2008.

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.

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 portions of this volume of POSIX.1-2008. The default rules include rules for optional commands in this volume of POSIX.1-2008. Only rules pertaining to commands that are provided are needed in the default set of an implementation.

One point of discussion was whether to drop the default rules list from this volume of POSIX.1-2008. 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 was 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 or specified on the make command line and not by a user running make.

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(1) 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 make s allow blank, empty, or comment 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 blank, empty, and comment lines 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.

Some implementations do not use system(3) 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(3). There is no requirement that system(3) be used specifically, but merely that the same results be achieved. The metacharacters typically used to bypass the direct execve(3) 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 make s solves this problem in a more general way. This volume of POSIX.1-2008 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.

FUTURE DIRECTIONS

None.

SEE ALSO

Shell Command Language, ar(1), c99(1), get(1), lex(1), sccs(1), sh(1), yacc(1)

XBD V1_chap06(7), V1_chap08(7), V1_chap12(7)

XSH exec(3), system(3)

CHANGE HISTORY

First released in Issue 2.

Issue 5

The FUTURE DIRECTIONS section is added.

Issue 6

This utility is marked as part of the Software Development Utilities option.

The Open Group Corrigendum U029/1 is applied, correcting a typographical error in the SPECIAL TARGETS section.

In the ENVIRONMENT VARIABLES section, the PROJECTDIR description is updated from "otherwise, the home directory of a user of that name is examined" to "otherwise, the value of PROJECTDIR is treated as a user name and that user's initial working directory is examined".

It is specified whether the command line is related to the makefile or to the make command, and the macro processing rules are updated to align with the IEEE P1003.2b draft standard.

The normative text is reworded to avoid use of the term "must" for application requirements.

PASC Interpretation 1003.2 #193 is applied.

Issue 7

SD5-XCU-ERN-6 is applied, clarifying that Guideline 9 of the Utility Syntax Guidelines does not apply.

SD5-XCU-ERN-97 is applied, updating the SYNOPSIS.

Include lines in makefiles are introduced.

Austin Group Interpretation 1003.1-2001 #131 is applied, changing the Makefile Execution section.

POSIX.1-2008, Technical Corrigendum 1, XCU/TC1-2008/0121 [257] is applied.

End of informative text.