MAKE(1P)

📦 version 2017a, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, nixpkgs unstable, opensuse-leap 16.0

💖 MAKE(1P) 💖 — maintain, update, and regenerate groups of programs (DEVELOPMENT)

🌸 PROLOG 🌸

okay so bestie, 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 on 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):
    • The characters are option letters without the leading <hyphen-minus> 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-minus> characters and <blank>-separated as described in the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines. 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 Section 2.6, Word Expansions) associated with parsing the command line values.
  • 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.

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

ok so bestie, every command make is gonna run gets written to standard output. every single one. unlesssss:

  • the -s option was specified, or
  • the command is prefixed with an at-sign, or
  • the special target .SILENT either has the current target as a prerequisite, or has no prerequisites at all.

And if you invoke make and literally nothing needs doing? It writes a message to standard output telling you no action was taken. so polite of it fr fr 💖

Oh and if the -t option is present and a file gets touched, make writes a message to standard output — format unspecified, no cap — indicating that the file was touched, and it includes the filename of the file. 🎀

😭 STDERR

Standard error is used for diagnostic messages and literally nothing else. that's its whole job. that's its whole vibe. periodt.

📁 OUTPUT FILES

Files can be created when the -t option is present. Also, additional files can be created by the utilities that make invokes. so yeah, the side effects are real. 🙈

✨ EXTENDED DESCRIPTION ✨

okay this is the main character section, sit down, hydrate, let's go. 🫶

make tries to do all the actions required to make sure 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
  • it has already been made up-to-date by the current invocation of make — regardless of the target's existence or age. the way that it just remembers…

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).

make shall treat all prerequisites as targets themselves and recursively ensure they're up-to-date, processing them in the order in which they appear in the rule. And it uses the modification times of files to figure out whether the corresponding targets are out-of-date. timestamps are the whole plot device here ⏰

To make sure a target is up-to-date, make shall ensure that all of the prerequisites of a target are up-to-date, and then check whether the target itself is up-to-date. If the target isn't up-to-date, it gets made up-to-date by executing the rule's commands (if any). And if the target doesn't exist after being successfully made up-to-date, it shall be treated as being newer than any target for which it is a prerequisite. 💅

If a target exists and there's neither a target rule nor an inference rule for it, the target shall be considered up-to-date. slay, nothing to do.

⚠️ It shall be an error if make attempts to ensure 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. no rule, no file, no mercy. 💀

🧁 Makefile Syntax

A makefile can contain rules, macro definitions (peep Macros), include lines, and comments. And there are two kinds of rules: inference rules and target rules.

make shall contain a set of built-in inference rules. If the -r option is present, those built-in rules shall not be used, and the suffix list shall be cleared. 🧹

Additional rules of both types can be specified in a makefile. And if a rule is defined more than once, the value of the rule shall be that of the last one specified. Macros can also be defined more than once — the value of the macro is specified in Macros.

There are three kinds of comments:

  • blank lines,
  • empty lines, and
  • a <number-sign> ('#') plus all following characters up to the first unescaped <newline> character.

Blank lines, empty lines, and lines with <number-sign> ('#') as the first character on the line are also known as comment lines. 🎀

By default, these files shall be tried in sequence: ./makefile and ./Makefile. If neither ./makefile nor ./Makefile are found, other implementation-defined files may also be tried. On XSI-conformant systems, the additional files ./s.makefile, SCCS/s.makefile, ./s.Makefile, and SCCS/s.Makefile shall also be tried. the XSI girls get extra files, iykyk

The -f option shall direct make to ignore any of these default files and use the specified argument as a makefile instead. And if the '-' argument is specified, standard input shall be used. ⭐

The term makefile is used to refer to any rules provided by the user — whether in ./makefile or its variants, or specified by the -f option.

The rules in makefiles shall consist of these types of lines: target rules (including special targets, peep Target Rules), inference rules (peep Inference Rules), macro definitions (peep Macros), and comments.

Target and Inference Rules may contain command lines. Command lines can have a prefix that shall be removed before execution (peep Makefile Execution). ✂️

Now, the escaped-<newline> lore, because this is genuinely important bestie:

  • When an escaped <newline> (one preceded by a <backslash>) is found anywhere in the makefile except in a command line, an include line, or a line immediately preceding an include line, it shall be replaced — along with any leading white space on the following line — with a single <space>.
  • When an escaped <newline> is found in a command line in a makefile, the command line shall contain the <backslash>, the <newline>, and the next line — except that the first character of the next line shall not be included if it's a <tab>.
  • When an escaped <newline> is found in an include line or in a line immediately preceding an include line, the behavior is unspecified. we do not know, nobody knows, do not ask. 😭

📥 Include Lines

If the word include appears at the beginning of a line and is followed by one or more <blank> characters, the string formed by the rest of the line shall be processed like this to produce a pathname:

  • The trailing <newline>, any <blank> characters immediately preceding a comment, and any comment shall be discarded. If the resulting string contains any double-quote characters ('"') the behavior is unspecified.
  • The resulting string shall be processed for macro expansion (peep Macros).
  • Any <blank> characters that appear after the first non-<blank> shall be used as separators to divide the macro-expanded string into fields. It is unspecified whether any other white-space characters are also used as separators. It is unspecified whether pathname expansion (peep Section 2.13, Pattern Matching Notation) is also performed.
  • If the processing of separators and optional pathname expansion results in either zero or two or more non-empty fields, the behavior is unspecified. If it results in one non-empty field, that field is taken as the pathname. one field, one destiny

If the pathname does not begin with a '/' it shall be treated as relative to the current working directory of the process — not relative to the directory containing the makefile. If the file doesn't exist in this location, it is unspecified whether additional directories are searched. 👑

The contents of the file specified by the pathname shall be read and processed as if they appeared in the makefile in place of the include line. If the file ends with an escaped <newline> the behavior is unspecified. unspecified again, we stay unbothered

The file may itself contain further include lines. Implementations shall support nesting of include files up to a depth of at least 16. 🪆

🏃 Makefile Execution

Makefile command lines shall be processed one at a time. no multitasking, no chaos (well, some chaos).

Makefile command lines can have one or more of these prefixes: a <hyphen-minus> ('-'), an at-sign ('@'), or a <plus-sign> ('+'). These shall modify the way make processes the command:

  • - — If the command prefix contains a <hyphen-minus>, or the -i option is present, or the special target .IGNORE either has the current target as a prerequisite or has no prerequisites, any error found while executing the command shall be ignored. girl, we pretend we didn't see it
  • @ — If the command prefix contains an at-sign and the make utility command line -n option is not specified, or the -s option is present, or the special target .SILENT either has the current target as a prerequisite or has no prerequisites, the command shall not be written to standard output before it is executed. 🤫
  • + — If the command prefix contains a <plus-sign>, this indicates a makefile command line that shall be executed even if -n, -q, or -t is specified. it simply must run

An execution line is built from the command line by removing any prefix characters. Except as described under the at-sign prefix, the execution line shall be written to the standard output, optionally preceded by a <tab>. The execution line shall then be executed by a shell as if it were passed as the argument to the system() interface — except that if errors are not being ignored, then the shell -e option shall also be in effect. If errors are being ignored for the command (as a result of the -i option, a '-' command prefix, or a .IGNORE special target), the shell -e option shall not be in effect. The environment for the command being executed shall contain all of the variables in the environment of make. 🌸

😤 By default, when make receives a non-zero status from the execution of a command, it shall terminate with an error message to standard error.

🎯 Target Rules

Target rules are formatted like this:

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

line that does not begin with <tab>

Target entries are specified by a <blank>-separated, non-null list of targets, then a <colon>, then a <blank>-separated, possibly empty list of prerequisites. Text following a <semicolon>, if any, and all following lines that begin with a <tab>, are makefile command lines to be executed to update the target. The first non-empty line that does not begin with a <tab> or '#' shall begin a new entry. Any comment line may begin a new entry. 🦋

Applications shall select target names from the set of characters consisting solely of periods, underscores, digits, and alphabetics from the portable character set (peep the Base Definitions volume of POSIX.1‐2017, Section 6.1, Portable Character Set). Implementations may allow other characters in target names as extensions. The interpretation of targets containing the characters '%' and '"' is implementation-defined. 💅

A target that has prerequisites, but does not have any commands, can be used to add to the prerequisite list for that target. And only one target rule for any given target can contain commands. one rule to command them all

Lines that begin with one of the following are called special targets and control the operation of make:

  • .DEFAULT — If the makefile uses this special target, the application shall ensure that it is specified with commands, but without prerequisites. The commands shall be used by make if there are no other rules available to build a target. the fallback bestie, the emergency contact 🫶
  • .IGNORE — the prerequisites here are targets themselves, and listing them makes errors from commands tied to those targets get ignored, same energy as the -i option. Every new .IGNORE line just keeps adding to the list of targets that ignore command errors. If you give it no prerequisites, make acts like -i was passed and errors from all commands on all targets get ignored. no cap. 🫶
  • .POSIX — the application shall make sure this special target is specified with no prerequisites and no commands. If it shows up as the first non-comment line in the makefile, make shall process the makefile exactly as specified by this section. Otherwise? bestie, the behavior of make is unspecified. 🙈
  • .PRECIOUS — prerequisites of this special target shall not be removed if make receives one of the asynchronous events explicitly described in the ASYNCHRONOUS EVENTS section. Later .PRECIOUS lines just keep adding to the list of precious files. No prerequisites at all? Then every target in the makefile gets treated as if it had been specified with .PRECIOUS. 💎
  • .SCCS_GET — the application shall make sure this special target is specified with no prerequisites. If it's in a makefile, the commands specified with this target shall replace the default commands associated with this special target (see Default Rules). Those commands are what's used to get all SCCS files that are not found in the current directory.

When source files are named in a dependency list, make shall treat them just like any other target. Since the source file is presumed to already be present in the directory, there's no need to add an entry for it to the makefile. And when a target has no dependencies but is present in the directory, make shall assume that file is up-to-date. But if an SCCS file named SCCS/s.source_file is found for a target source_file, make compares the timestamp of the target file with that of the SCCS/s.source_file to make sure the target is up-to-date. If the target is missing, or if the SCCS file is newer, make shall automatically issue the commands specified for the .SCCS_GET special target to retrieve the most recent version. However — if the target is writable by anyone, make shall not retrieve a new version. 🚫

  • .SILENT — prerequisites are targets themselves, and this makes the commands associated with them not be written to standard output before they run. Later .SILENT lines keep adding to the list of targets with silent commands. If you give it no prerequisites, make acts like -s was specified and no commands or touch messages associated with any target shall be written to standard output. shhh 🤫
  • .SUFFIXES — prerequisites of .SUFFIXES shall be appended to the list of known suffixes and get used together with the inference rules (see Inference Rules). If .SUFFIXES has no prerequisites at all, the list of known suffixes shall be cleared. ✨
The special targets .IGNORE, .POSIX, .PRECIOUS, .SILENT, and .SUFFIXES shall be specified without commands. periodt.

Targets with names made of a leading <period> followed by the uppercase letters "POSIX" and then any other characters are reserved for future standardization. Targets with names made of a leading <period> followed by one or more uppercase letters are reserved for implementation extensions. 🔒

🧚 Macros 🧚

Macro definitions are in the form:

string1 = [string2]

The macro named string1 is defined as having the value of string2, where string2 is defined as all characters, if any, after the <equals-sign>, up to a comment character ('#') or an unescaped <newline>. Any <blank> characters immediately before or after the <equals-sign> shall be ignored. ✨

Applications shall select macro names from the set of characters consisting solely of periods, underscores, digits, and alphabetics from the portable character set (see the Base Definitions volume of POSIX.1‐2017, Section 6.1, Portable Character Set). A macro name shall not contain an <equals-sign>. Implementations may allow other characters in macro names as extensions. 👑

Macros can appear anywhere in the makefile. Macro expansions using the forms $(string1) or ${string1} shall be replaced by string2, as follows:

  • Macros in target lines shall be evaluated when the target line is read. 📖
  • Macros in makefile command lines shall be evaluated when the command is executed. ⚡
  • Macros in the string before the <equals-sign> in a macro definition shall be evaluated when the macro assignment is made. ✍️
  • Macros after the <equals-sign> in a macro definition shall not be evaluated until the defined macro is used in a rule or command, or before the <equals-sign> in a macro definition. ⏳

The parentheses or braces are optional if string1 is a single character. The macro $$ shall be replaced by the single character '$'. If string1 in a macro expansion contains a macro expansion, the results are unspecified. 😵‍💫

Macro expansions using the forms $(string1[:subst1=[subst2]]) or ${string1[:subst1=[subst2]]} can be used to replace all occurrences of subst1 with subst2 when the macro substitution is performed. The subst1 to be replaced shall be recognized when it is a suffix at the end of a word in string1 (where a word, in this context, is defined to be a string delimited by the beginning of the line, a <blank>, or a <newline>). If string1 in a macro expansion contains a macro expansion, the results are unspecified. If a <percent-sign> character appears as part of subst1 or subst2 after any macros have been recursively expanded, the results are unspecified. 🌀

Macro expansions in string1 of macro definition lines shall be evaluated when read. Macro expansions in string2 of macro definition lines shall be performed when the macro identified by string1 is expanded in a rule or command.

Macro definitions shall be taken from the following sources, in the following logical order, before the makefile(s) are read. 🫡

  1. Macros specified on the make utility command line, in the order specified on the command line. It is unspecified whether the internal macros defined in Internal Macros are accepted from this source.
  2. Macros defined by the MAKEFLAGS environment variable, in the order specified in the environment variable. It is unspecified whether the internal macros defined in Internal Macros are accepted from this source.
  3. The contents of the environment, excluding the MAKEFLAGS and SHELL variables and including the variables with null values.
  4. Macros defined in the inference rules built into make.

Macro definitions from these sources shall not override macro definitions from a lower-numbered source. Macro definitions from a single source (for example, the make utility command line, the MAKEFLAGS environment variable, or the other environment variables) shall override previous macro definitions from the same source. 🏆

Macros defined in the makefile(s) shall override macro definitions that occur before them in the makefile(s) and macro definitions from source 4. If the -e option is not specified, macros defined in the makefile(s) shall override macro definitions from source 3. Macros defined in the makefile(s) shall not override macro definitions from source 1 or source 2. 🚫

Before the makefile(s) are read, all of the make utility command line options (except -f and -p) and make utility command line macro definitions (except any for the MAKEFLAGS macro), not already included in the MAKEFLAGS macro, shall be added to the MAKEFLAGS macro, quoted in an implementation-defined manner such that when MAKEFLAGS is read by another instance of the make command, the original macro's value is recovered. Other implementation-defined options and macros may also be added to the MAKEFLAGS macro. If this modifies the value of the MAKEFLAGS macro, or, if the MAKEFLAGS macro is modified at any subsequent time, the MAKEFLAGS environment variable shall be modified to match the new value of the MAKEFLAGS macro. The result of setting MAKEFLAGS in the Makefile is unspecified. 😬

Before the makefile(s) are read, all of the make utility command line macro definitions (except the MAKEFLAGS macro or the SHELL macro) shall be added to the environment of make. Other implementation-defined variables may also be added to the environment of make. Macros defined by the MAKEFLAGS environment variable and macros defined in the makefile(s) shall not be added to the environment of make if they are not already in its environment. With the exception of SHELL (see below), it is unspecified whether macros defined in these ways update the value of an environment variable that already exists in the environment of make. 🌱

The SHELL macro shall be treated specially. It shall be provided by make and set to the pathname of the shell command language interpreter (see sh). The SHELL environment variable shall not affect the value of the SHELL macro. If SHELL is defined in the makefile or is specified on the command line, it shall replace the original value of the SHELL macro, but shall not affect the SHELL environment variable. Other effects of defining SHELL in the makefile or on the command line are implementation-defined. 🐚

🔥 Inference Rules 🔥

Inference rules are formatted as follows:

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

line that does not begin with <tab> or #

The application shall ensure that the target portion is a valid target name (see Target Rules) of the form .s2 or .s1.s2 (where .s1 and .s2 are suffixes that have been given as prerequisites of the .SUFFIXES special target and s1 and s2 do not contain any <slash> or <period> characters.) If there is only one <period> in the target, it is a single-suffix inference rule. Targets with two periods are double-suffix inference rules. Inference rules can have only one target before the <colon>. 💅

The application shall ensure that the makefile does not specify prerequisites for inference rules; no characters other than white space shall follow the <colon> in the first line, except when creating the empty rule, described below. Prerequisites are inferred, as described below. 🦋

Inference rules? they can be redefined. 💅 A target that matches an existing inference rule shall overwrite the old inference rule. periodt.

An empty rule can be created with a command that's just a <semicolon> — that is, the rule still exists and is found during inference rule search, but since it's empty, execution has no effect. 🙈 The empty rule can also be formatted like this:

rule: ;

where zero or more <blank> characters separate the <colon> and <semicolon>. cute.

The make utility uses the suffixes of targets and their prerequisites to infer how a target can be made up-to-date. A list of inference rules defines the commands to be executed. By default, make contains a built-in set of inference rules. Additional rules can be specified in the makefile. slay.

The special target .SUFFIXES contains as its prerequisites a list of suffixes that shall be used by the inference rules. The order in which the suffixes are specified defines the order in which the inference rules for the suffixes are used. New suffixes shall be appended to the current list by specifying a .SUFFIXES special target in the makefile. A .SUFFIXES target with no prerequisites shall clear the list of suffixes. An empty .SUFFIXES target followed by a new .SUFFIXES list is required to change the order of the suffixes. 💖

Normally, the user would provide an inference rule for each suffix. The inference rule to update a target with a suffix .s1 from a prerequisite with a suffix .s2 is specified as a target .s2.s1. The internal macros provide the means to specify general inference rules (see Internal Macros). ✨

When no target rule is found to update a target, the inference rules shall be checked. The suffix of the target (.s1) to be built is compared to the list of suffixes specified by the .SUFFIXES special targets. If the .s1 suffix is found in .SUFFIXES, the inference rules shall be searched in the order defined for the first .s2.s1 rule whose prerequisite file ($*.s2) exists. If the target is out-of-date with respect to this prerequisite, the commands for that inference rule shall be executed. 🔥

If the target to be built does not contain a suffix and there is no rule for the target, the single suffix inference rules shall be checked. The single-suffix inference rules define how to build a target if a file is found with a name that matches the target name with one of the single suffixes appended. A rule with one suffix .s2 is the definition of how to build target from target.s2. The other suffix (.s1) is treated as null. 💀

A <tilde> (~) in the above rules refers to an SCCS file in the current directory. Thus, the rule .c~.o would transform an SCCS C-language source file into an object file (.o). Because the s. of the SCCS files is a prefix, it is incompatible with make's suffix point of view. Hence, the ~ is a way of changing any file reference into an SCCS file reference. 🌸

📚 Libraries 📚

If a target or prerequisite contains parentheses, it shall be treated as a member of an archive library. For the lib(member.o) expression, lib refers to the name of the archive library and member.o to the member name. The application shall ensure that the member is an object file with the .o suffix. The modification time of the expression is the modification time for the member as kept in the archive library; see ar. The .a suffix shall refer to an archive library. The .s2.a rule shall be used to update a member in the library from a file with a suffix .s2. 🫶

🧠 Internal Macros 🧠

The make utility shall maintain five internal macros that can be used in target and inference rules. In order to clearly define the meaning of these macros, some clarification of the terms target rule, inference rule, target, and prerequisite is necessary. 💅

Target rules are specified by the user in a makefile for a particular target. Inference rules are user-specified or make-specified rules for a particular class of target name. Explicit prerequisites are those prerequisites specified in a makefile on target lines. Implicit prerequisites are those prerequisites that are generated when inference rules are used. Inference rules are applied to implicit prerequisites or to explicit prerequisites that do not have target rules defined for them in the makefile. Target rules are applied to targets specified in the makefile. ✨

Before any target in the makefile is updated, each of its prerequisites (both explicit and implicit) shall be updated. This shall be accomplished by recursively processing each prerequisite. Upon recursion, each prerequisite shall become a target itself. Its prerequisites in turn shall be processed recursively until a target is found that has no prerequisites, or further recursion would require applying two inference rules one immediately after the other, at which point the recursion shall stop. As an extension, implementations may continue recursion when two or more successive inference rules need to be applied; however, if there are multiple different chains of such rules that could be used to create the target, it is unspecified which chain is used. The recursion shall then back up, updating each target as it goes. 😭

In the definitions that follow, the word target refers to one of:

  • A target specified in the makefile
  • An explicit prerequisite specified in the makefile that becomes the target when make processes it during recursion
  • An implicit prerequisite that becomes a target when make processes it during recursion

In the definitions that follow, the word prerequisite refers to one of the following:

  • An explicit prerequisite specified in the makefile for a particular target
  • An implicit prerequisite generated as a result of locating an appropriate inference rule and corresponding file that matches the suffix of the target

The five internal macros are:

  • $@ — The $@ shall evaluate to the full target name of the current target, or the archive filename part of a library archive target. It shall be evaluated for both target and inference rules.

For example, in the .c.a inference rule, $@ represents the out-of-date .a file to be built. Similarly, in a makefile target rule to build lib.a from file.c, $@ represents the out-of-date lib.a. 👑

  • $% — The $% macro shall be evaluated only when the current target is an archive library member of the form libname(member.o). In these cases, $@ shall evaluate to libname and $% shall evaluate to member.o. The $% macro shall be evaluated for both target and inference rules.

For example, in a makefile target rule to build lib.a(file.o), $% represents file.o, as opposed to $@, which represents lib.a. 💖

  • $? — The $? macro shall evaluate to the list of prerequisites that are newer than the current target. It shall be evaluated for both target and inference rules.

For example, in a makefile target rule to build prog from file1.o, file2.o, and file3.o, and where prog is not out-of-date with respect to file1.o, but is out-of-date with respect to file2.o and file3.o, $? represents file2.o and file3.o. 🔥

  • $< — In an inference rule, the $< macro shall evaluate to the filename whose existence allowed the inference rule to be chosen for the target. In the .DEFAULT rule, the $< macro shall evaluate to the current target name. The meaning of the $< macro shall be otherwise unspecified.

For example, in the .c.a inference rule, $< represents the prerequisite .c file. 🌸

  • $* — The $* macro shall evaluate to the current target name with its suffix deleted. It shall be evaluated at least for inference rules.

For example, in the .c.a inference rule, $*.o represents the out-of-date .o file that corresponds to the prerequisite .c file. 💅

Each of the internal macros has an alternative form. When an uppercase D or F is appended to any of the macros, the meaning shall be changed to the directory part for D and filename part for F. The directory part is the path prefix of the file without a trailing <slash>; for the current directory, the directory part is .. When the $? macro contains more than one prerequisite filename, the $(?D) and $(?F) (or ${?D} and ${?F}) macros expand to a list of directory name parts and filename parts respectively. 🦋

For the target lib(member.o) and the s2.a rule, the internal macros shall be defined as:

$<      member.s2

$*      member

$@      lib

$?      member.s2

$%      member.o

🌟 Default Rules 🌟

The default rules for make shall achieve results that are the same as if the following were used. Implementations that do not support the C-Language Development Utilities option may omit CC, CFLAGS, YACC, YFLAGS, LEX, LFLAGS, LDFLAGS, and the .c, .y, and .l inference rules. Implementations that do not support FORTRAN may omit FC, FFLAGS, and the .f inference rules. Implementations may provide additional macros and rules. 💀

       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 🚪

Okay bestie, here's the thing — make exits with different codes depending on whether you passed -q or not, so pay attention 💅

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 🛠️

So real talk: if there's a source file (like ./source.c) and there are two SCCS files matching it (./s.source.c and ./SCCS/s.source.c), then on XSI-conformant systems make uses the SCCS file in the current directory. But — and I cannot stress this enough — 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 get used for the same source file, future developers are very likely to be confused. Do not do that to them 🙈

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. So, like:

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. Sneaky, right? 😭

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

makes the first target found in the makefile.

  1. The following command:
make junk

makes the target junk.

  1. 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
  1. An example for making optimized .o files from .c files is:
.c.o:
    c99 -c -O 1 $*.c

or:

.c.o:
    c99 -c -O 1 $<
  1. 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
  1. 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).

So like, the syntax that this make specifies is basically a subset of what literally every other make out there accepts, so the standards people were like "changing the name would be counter-productive, bestie" 💀 and left it. And since the makefile itself is the actual basic unit of portability, reserving a new option letter — like make -P — to get the portable behavior wouldn't even fully work. So instead they added the special target .POSIX to the makefile, letting you ask for the ``standard'' behavior ✨.

And that special target is not blocking extensions in make itself, and it's not blocking a makefile from using those extensions either. What it does block: any extension that would change how previously-valid syntax behaves. Those extensions have to be controlled through command line options or new special targets instead. So the tea is: it's on you, portable makefile writer, to put .POSIX in your makefile if you wanna be guaranteed you're not getting blindsided by whatever local extensions your system decided to ship. 💅

The portable make in this page is not trying to be the state-of-the-art software generation tool, okay? Not everything new and leading-edge made it in. But they did try to write up the portable makefile in a way that doesn't preclude those extensions — as long as those extensions don't mess with the portable behavior described here. 🦋

When the -n option is specified, it's always added to MAKEFLAGS. Why? So you can do a recursive make -n target and see all of the action that would be taken to update target. Iconic behavior tbh. 👑

The definition of MAKEFLAGS allows both the System V letter string and the BSD command line formats. And the two formats are sufficiently different that implementations can support both without ambiguity. Two vibes, one variable, no drama. 🌸

Early proposals said an ``unquoted'' <number-sign> was treated as the start of a comment. But make does not pay any attention to quotes, bestie. A <number-sign> starts a comment regardless of its surroundings. No cap. 🎀

The text about ``other implementation-defined pathnames may also be tried'' — you know, the stuff beyond ./makefile and ./Makefile — exists to allow extensions like SCCS/s.Makefile and other variations. And they made it an implementation-defined requirement (not just unspecified behavior) specifically to highlight surprising implementations that might go pick something unexpected like /etc/Makefile 😭. XSI-conformant systems also try ./s.makefile, SCCS/s.makefile, ./s.Makefile, and SCCS/s.Makefile. The more you know 💫

Early proposals had the macro NPROC as a way to say "make should use n processes to do the work required". And like, that's a genuinely valuable extension for a lot of systems, but it's not common usage and could require other non-trivial extensions to makefile syntax. So this volume of POSIX.1‐2017 does not require it — but it could be provided as a compatible extension. Some historical systems use the macro PARALLEL with essentially the same meaning (just without a name that's also a common system limit value, iykyk). The suggestion: implementors should recognize the existing use of NPROC and/or PARALLEL as extensions to make. 🧚

The default rules are based on System V. And the default CC= value is c99 instead of cc, because this volume of POSIX.1‐2017 does not standardize the utility named cc. So every conforming application would be required to define CC=c99 to expect to run. There's no advantage from hoping the makefile might hit the ``preferred'' compiler, because that cannot be guaranteed to work. And also, since the portable makescript can only use the c99 options, no advantage is conferred in terms of what the script can do. Whether c99 is as valuable as cc is a quality-of-implementation issue. 🤷‍♀️

The -d option to make is frequently used to produce debugging information, but it's 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 changing that would cause many implementations to break without sufficiently increased portability. So it stays out. 🙈

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 got pointed out with this example of a portion of a makefile:

subdir:
    cd subdir; rm all_the_files; $(MAKE)

Like... do you see the problem 😭. The loss of the System V behavior in this case is well-balanced by the safety afforded to other makefiles that weren't aware of this situation. And in any event, the command line <plus-sign> prefix can provide the desired functionality. Bestie, use the prefix. 💅

The double <colon> in the target rule format is supported in BSD systems to let more than one target line containing the same target name 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: implementations should be able to use the rules without change, but they're allowed to alter them in ways that don't affect the primary behavior. 🦋

One point of discussion was whether to drop the default rules list from this volume of POSIX.1‐2017 entirely. They provide convenience, sure, but they don't enhance portability of applications. The prime benefit is portability for users who wanna just type make command and have the command build from a command.c file. Honestly? Fair. 🌸

The historical MAKESHELL feature, and related features from other make implementations, were omitted. In some implementations it's used to let a user override the shell used to run make commands. This was confusing; for a portable make, the shell should be chosen by the makefile writer. Also, a makefile writer can't 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"

slay, no extra standard needed. 💜

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's widely used historically. Implementations that wanna update prerequisites in parallel should require an explicit extension to make or the makefile format to accomplish it, as described previously. No sneaky reordering, bestie. 🚫

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. So like... tab discipline, besties. 📏

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's 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. Two cores, one moment, absolute chaos 💀. 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 — that's what specifying no prerequisites does. And the .IGNORE and .SILENT special targets were extended to allow prerequisites; it was judged 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, so no. 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. That's the whole vibe check. 🫶

Some implementations don't use system() for all command lines, even though the portable makefile format requires it. As a performance enhancement, they select lines without shell metacharacters for direct execution by execve(). There's 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

Noted, memorized, never forgetting. 🧚

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 advantages in performance and in not requiring 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. ✨

So yeah — one shell per line by default, .ONESHELL if you're feeling spicy and your implementation supports it. That's the whole thing, bestie. 💅

okay so bestie, real talk — the whole <tab> vs <space> saga 😭 New folks using make have always tripped over that old-school rule where commands have to start with a <tab>. And like, honestly? <tab> and <space> look basically identical on a terminal or a printout, so you get these cursed bugs that make zero sense. In the early proposals they tried to fix it by letting leading <blank> characters stand in for <tab>. But implementors came back like "bestie no" — tons of makefiles broke in the most subtle, sneaky ways after that change, and it's genuinely hard to build a make that can unambiguously tell macro lines apart from command lines. Meanwhile there's sooo much historical practice of letting leading <space> characters chill before macro definitions. Forcing macro lines into column 1 would be a major backwards-compatibility glow-down for some makefiles. So yeah — historical practice got restored. periodt. 💅

The way different implementations handle include lines varies a lot. But there's enough shared behavior that the standard can still lay out a minimum set of requirements so you can actually use the feature portably. All the known variations got called out explicitly as unspecified behavior in the description. iykyk. ✨

The System V dynamic dependency feature did not make the cut. If it had, it would support stuff like:

cat: $$@.c

which would expand to:

cat: cat.c

That feature only exists in the new version of System V make, and while it's lowkey useful, it's just not widely used. What this means is that macros get expanded twice for prerequisites: once at makefile parse time, and once at target update time. 🙈

They also considered adding metarules to POSIX make, which would make %.o: %.c the same as .c.o:. Super useful, and some vendors ship it, but it would've caused way too many changes to this make to support. It would've introduced rule chaining and new substitution rules. However — the rules for target names have been set to reserve the '%' and '"' characters. Those are traditionally used to implement metarules and quoting of target names, respectively. Implementors are strongly encouraged to use these characters only for those purposes. no cap. 👑

Someone asked to extend the suffix delimiter character from a <period> to any character. But the metarules feature in newer makes solves that problem in a more general way, so this volume of POSIX.1‐2017 is staying with the more conservative historical definition. it's giving tradition. 🎀

The standard output format for the -p option is not described, because it's primarily a debugging option and the format isn't generally useful to programs. In historical implementations the output isn't suitable for generating makefiles. The -p format has been all over the place across historical implementations. So the definition of -p was only ever meant to provide a consistently named option for getting make script debugging information. 💀

Also — some historical implementations have not cleared the suffix list with -r. noted.

Implementations should be aware that some historical applications have intermixed target_name and macro=value operands on the command line, expecting all the macros to be processed before any of the targets get dealt with. Conforming applications don't do this, but some backwards-compatibility support may be warranted. 🫶

Empty inference rules are specified with a <semicolon> command rather than omitting all commands, like an early proposal suggested. That 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. Then lots of places started talking 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 explicitly 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 instead. 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 make sure 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. manifesting it bestie ✨

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()

like, go read those if you want the full lore. 📚💖

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 .

friendly lil heads-up bestie: if something looks off, the original IEEE / The Open Group Standard is the referee document, so that's the one that wins. 🫶

and that's a wrap on the whole page, bestie!! 🎉 This one's from IEEE/The Open Group, dated 2017, and it's the MAKE(1P) man page. tysm for reading all seven parts, you're literally the main character for finishing this 💅✨ mwah, go build something iconic 🦋🌸

📦 where this page comes from