xenial (1) make.1posix.gz

Provided by: manpages-posix_2013a-1_all bug

PROLOG

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

NAME

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

SYNOPSIS

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

DESCRIPTION

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

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

        2. Target rules, which can have more than one target name

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

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

        *  Include the special target .POSIX

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

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

OPTIONS

       The  make  utility  shall  conform  to the Base Definitions volume of POSIX.1‐2008, 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, 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‐2008, 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>  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 the
                     Base  Definitions  volume  of  POSIX.1‐2008,  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

       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.

   Makefile Syntax
       A makefile can contain rules, macro definitions (see Macros), include lines, and comments. There are  two
       kinds  of  rules:  inference  rules  and  target rules.  The make utility shall contain a set of built-in
       inference rules. If the −r option is present, the 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. 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, and the value of the macro is specified in Macros.  Comments start with a <number-sign>
       ('#') and continue until an unescaped <newline> is reached.

       By default, the following files shall be tried  in  sequence:  ./makefile  and  ./Makefile.   If  neither
       ./makefile  or  ./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  −f option shall direct make to ignore any of these default files and use the specified argument as a
       makefile instead. 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 the following types of lines: target rules, including special
       targets (see Target Rules), inference rules (see Inference Rules), macro definitions (see Macros),  empty
       lines, and comments.

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

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

   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 remainder of the line shall be processed as follows to produce a pathname:

        *  The  trailing  <newline>  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 (see 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  (see  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.

       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  does  not
       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.

       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.

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

       −     If  the  command  prefix  contains  a  <hyphen>, or the −i option is present, or the special target
             .IGNORE has either the current target as a prerequisite or has no prerequisites,  any  error  found
             while executing the command shall be ignored.

       @     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 has either 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.

       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 as follows:

           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. An empty or
       blank line, or a line beginning with '#', 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 (see the Base Definitions volume of
       POSIX.1‐2008, 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. Only one target rule for any given target can contain commands.

       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.

       .IGNORE   Prerequisites  of  this  special  target  are  targets themselves; this shall cause errors from
                 commands associated with them to be ignored in the same manner as specified by the  −i  option.
                 Subsequent  occurrences of .IGNORE shall add to the list of targets ignoring command errors. If
                 no prerequisites are specified, make shall behave as if the −i option had  been  specified  and
                 errors from all commands associated with all targets shall be ignored.

       .POSIX    The  application  shall  ensure  that this special target is specified without prerequisites or
                 commands. If it appears as the first non-comment line in the makefile, make shall  process  the
                 makefile as specified by this section; otherwise, 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.  Subsequent
                 occurrences  of  .PRECIOUS  shall  add  to  the list of precious files. If no prerequisites are
                 specified, all targets in the makefile shall be treated as if specified with .PRECIOUS.

       .SCCS_GET The application shall ensure that this special target is specified  without  prerequisites.  If
                 this  special  target  is included in a makefile, the commands specified with this target shall
                 replace the default commands associated with this special  target  (see  Default  Rules).   The
                 commands  specified  with  this target are 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. Because the source file is presumed to be present in the directory, there is no need to
                 add an entry for it to the makefile. When a target has no dependencies, but is present  in  the
                 directory,  make  shall  assume  that  that file is up-to-date. If, however, 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 ensure 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 of this  special  target  are  targets  themselves;  this  shall  cause  commands
                 associated  with  them  not  to  be  written  to  the standard output before they are executed.
                 Subsequent occurrences of .SILENT shall add to the list of targets with silent commands. If  no
                 prerequisites  are  specified,  make shall behave as if the −s option had been specified and no
                 commands or touch messages associated with any target shall be written to standard output.

       .SUFFIXES Prerequisites of .SUFFIXES shall be appended to the list of known  suffixes  and  are  used  in
                 conjunction  with  the  inference  rules (see Inference Rules).  If .SUFFIXES does not have any
                 prerequisites, the list of known suffixes shall be cleared.

       The special targets .IGNORE, .POSIX,  .PRECIOUS,  .SILENT,  and  .SUFFIXES  shall  be  specified  without
       commands.

       Targets  with  names  consisting of a leading <period> followed by the uppercase letters "POSIX" and then
       any other characters are reserved for future standardization.  Targets with names consisting 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‐2008,  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.

       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.

       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  can  be redefined. A target that matches an existing inference rule shall overwrite the
       old inference rule. An empty rule can be created with a command consisting of simply a <semicolon>  (that
       is, the rule still exists and is found during inference rule search, but since it is empty, execution has
       no effect). The empty rule can also be formatted as follows:

           rule: ;

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

       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.

       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, at which point the recursion stops.  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
           FC=fort77
           FFLAGS=−O 1
           GET=get
           GFLAGS=
           SCCSFLAGS=
           SCCSGETFLAGS=−s

           SINGLE SUFFIX RULES

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

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

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

           .c~:
               $(GET) $(GFLAGS) −p $< > $*.c
               $(CC) $(CFLAGS) $(LDFLAGS) −o $@ $*.c

           .f~:
               $(GET) $(GFLAGS) −p $< > $*.f
               $(FC) $(FFLAGS) $(LDFLAGS) −o $@ $*.f

           .sh~:
               $(GET) $(GFLAGS) −p $< > $*.sh
               cp $*.sh $@
               chmod a+x $@

           DOUBLE SUFFIX RULES

           .c.o:
               $(CC) $(CFLAGS) −c $<

           .f.o:
               $(FC) $(FFLAGS) −c $<

           .y.o:
               $(YACC) $(YFLAGS) $<
               $(CC) $(CFLAGS) −c y.tab.c
               rm −f y.tab.c
               mv y.tab.o $@

           .l.o:
               $(LEX) $(LFLAGS) $<
               $(CC) $(CFLAGS) −c lex.yy.c
               rm −f lex.yy.c
               mv lex.yy.o $@

           .y.c:
               $(YACC) $(YFLAGS) $<
               mv y.tab.c $@

           .l.c:
               $(LEX) $(LFLAGS) $<
               mv lex.yy.c $@

           .c~.o:
               $(GET) $(GFLAGS) −p $< > $*.c
               $(CC) $(CFLAGS) −c $*.c

           .f~.o:
               $(GET) $(GFLAGS) −p $< > $*.f
               $(FC) $(FFLAGS) −c $*.f

           .y~.o:
               $(GET) $(GFLAGS) −p $< > $*.y
               $(YACC) $(YFLAGS) $*.y
               $(CC) $(CFLAGS) −c y.tab.c
               rm −f y.tab.c
               mv y.tab.o $@

           .l~.o:
               $(GET) $(GFLAGS) −p $< > $*.l
               $(LEX) $(LFLAGS) $*.l
               $(CC) $(CFLAGS) −c lex.yy.c
               rm −f lex.yy.c
               mv lex.yy.o $@

           .y~.c:
               $(GET) $(GFLAGS) −p $< > $*.y
               $(YACC) $(YFLAGS) $*.y
               mv y.tab.c $@

           .l~.c:
               $(GET) $(GFLAGS) −p $< > $*.l
               $(LEX) $(LFLAGS) $*.l
               mv lex.yy.c $@

           .c.a:
               $(CC) −c $(CFLAGS) $<
               $(AR) $(ARFLAGS) $@ $*.o
               rm −f $*.o

           .f.a:
               $(FC) −c $(FFLAGS) $<
               $(AR) $(ARFLAGS) $@ $*.o
               rm −f $*.o

EXIT STATUS

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

        0    Successful completion.

        1    The target was not up-to-date.

       >1    An error occurred.

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

        0    Successful completion.

       >0    An error occurred.

CONSEQUENCES OF ERRORS

       Default.

       The following sections are informative.

APPLICATION USAGE

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

       It is incumbent upon portable makefiles to specify the .POSIX special target in order to  guarantee  that
       they are not affected by local extensions.

       The  −k  and −S options are both present so that the relationship between the command line, the MAKEFLAGS
       variable, and the makefile can be controlled precisely. If the k  flag  is  passed  in  MAKEFLAGS  and  a
       command is of the form:

           $(MAKE) −S foo

       then the default behavior is restored for the child make.

       When the −n option is specified, it is always added to MAKEFLAGS.  This allows a recursive make −n target
       to be used to see all of the action that would be taken to update target.

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

           CFLAGS = "−D COMMENT_CHAR='#'"

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

       The best way to provide portable makefiles is to include all of the rules needed in the makefile  itself.
       The  rules provided use only features provided by other parts of this volume of POSIX.1‐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  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 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)

       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,  echo, and pax) and/or command line options have been provided to select the
       desired behavior (grep, od, and pax).

       Because the syntax specified for the make utility is, by and large, a subset of the syntaxes accepted  by
       almost  all versions of make, it was decided that it would be counter-productive to change the name.  And
       since the makefile itself is a basic unit of portability, it would not be completely effective to reserve
       a  new  option  letter,  such as make −P, to achieve the portable behavior. Therefore, the special target
       .POSIX was added to the makefile, allowing users to specify ``standard'' behavior.  This  special  target
       does  not preclude extensions in the make utility, nor does it preclude such extensions being used by the
       makefile specifying the target; it does, however, preclude any extensions from being applied  that  could
       alter  the  behavior  of  previously  valid  syntax;  such extensions must be controlled via command line
       options or new special targets. It is incumbent upon portable makefiles to  specify  the  .POSIX  special
       target in order to guarantee that they are not affected by local extensions.

       The  portable version of make described in this reference page is not intended to be the state-of-the-art
       software generation tool and, as such, some newer and more leading-edge features have not been  included.
       An  attempt  has  been  made  to  describe  the portable makefile in a manner that does not preclude such
       extensions as long as they do not disturb the portable behavior described here.

       When the −n option is specified, it is always added to MAKEFLAGS.  This allows a recursive make −n target
       to be used to see all of the action that would be taken to update target.

       The  definition of MAKEFLAGS allows both the System V letter string and the BSD command line formats. The
       two formats are sufficiently different to allow implementations to support both without ambiguity.

       Early proposals stated that an ``unquoted'' <number-sign> was treated as the start of a comment. The make
       utility  does  not  pay  any  attention  to  quotes.  A  <number-sign> starts a comment regardless of its
       surroundings.

       The text about ``other implementation-defined pathnames may also be tried'' in addition to ./makefile and
       ./Makefile  is  to  allow  such  extensions  as  SCCS/s.Makefile  and  other  variations.  It was made an
       implementation-defined  requirement  (as  opposed  to  unspecified  behavior)  to  highlight   surprising
       implementations  that  might select something unexpected like /etc/Makefile.  XSI-conformant systems also
       try ./s.makefile, SCCS/s.makefile, ./s.Makefile, and SCCS/s.Makefile.

       Early proposals contained the macro NPROC as a means of specifying that make should use n processes to do
       the  work  required.  While this feature is a valuable extension for many systems, it is not common usage
       and could require other non-trivial extensions to makefile syntax. This extension is not required by this
       volume  of  POSIX.1‐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 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 to expect to run. There is no advantage conferred by the hope that the makefile
       might  hit the ``preferred'' compiler because this cannot be guaranteed to work. Also, since the portable
       makescript can only use the c99 options, no advantage is conferred in terms of what the  script  can  do.
       It is a quality-of-implementation issue as to whether c99 is as valuable as cc.

       The  −d  option  to  make is frequently used to produce debugging information, but is too implementation-
       defined to add to this volume of POSIX.1‐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 programs; for example:

           foo: y.tab.o lex.o main.o
               $(CC) $(CFLAGS) −o $@ t.tab.o lex.o main.o

       In this example, if make chose any arbitrary order, the lex.o might not be made with the correct y.tab.h.
       Although there may be better  ways  to  express  this  relationship,  it  is  widely  used  historically.
       Implementations  that  desire to update prerequisites in parallel should require an explicit extension to
       make or the makefile format to accomplish it, as described previously.

       The algorithm for determining a new entry for target rules  is  partially  unspecified.  Some  historical
       makes  allow  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() for all command lines, as  required  by  the  portable  makefile
       format; as a performance enhancement, they select lines without shell metacharacters for direct execution
       by execve().  There is no requirement that system() be  used  specifically,  but  merely  that  the  same
       results be achieved.  The metacharacters typically used to bypass the direct execve() execution have been
       any of:

           =  |  ^  (  )  ;  &  <  >  *  ?  [  ]  :  $  `  '  "  \  \n

       The default in some advanced versions of make is to group all the command lines for a target and  execute
       them using a single shell invocation; the System V method is to pass each line individually to a separate
       shell. The single-shell method has the advantages in performance and the lack of a requirement  for  many
       continued  lines.  However,  converting  to  this  newer method has caused portability problems with many
       historical makefiles, so the behavior with the POSIX makefile is specified to be  the  same  as  that  of
       System  V.  It  is  suggested that the special target .ONESHELL be used as an implementation extension to
       achieve the single-shell grouping for a target or group of targets.

       Novice users of make have had difficulty with the historical need to start commands with a <tab>.   Since
       it is often difficult to discern differences between <tab> and <space> characters on terminals or printed
       listings, confusing bugs can arise. In early proposals, an attempt was made to correct  this  problem  by
       allowing  leading  <blank>  characters  instead  of <tab> characters. However, implementors reported many
       makefiles that failed in subtle ways following this change, and it is difficult to implement a make  that
       unambiguously  can differentiate between macro and command lines.  There is extensive historical practice
       of allowing leading <space> characters before macro definitions. Forcing macro lines into column 1  would
       be  a significant backwards-compatibility problem for some makefiles.  Therefore, historical practice was
       restored.

       There is substantial variation in the handling of include lines by  different  implementations.  However,
       there  is  enough  commonality  for the standard to be able to specify a minimum set of requirements that
       allow the feature to be used portably. Known variations have been explicitly called  out  as  unspecified
       behavior in the description.

       The System V dynamic dependency feature was not included. It would support:

           cat: $$@.c

       that would expand to;

           cat: cat.c

       This  feature  exists  only  in the new version of System V make and, while useful, is not in wide usage.
       This means that macros are expanded twice for prerequisites: once at makefile  parse  time  and  once  at
       target update time.

       Consideration  was  given  to  adding  metarules to the POSIX make.  This would make %.o: %.c the same as
       .c.o:.  This is quite useful and available from some vendors, but it would cause too many changes to this
       make  to  support.  It would have introduced rule chaining and new substitution rules. However, the rules
       for target names have been set to reserve the '%' and '"' characters. These  are  traditionally  used  to
       implement  metarules  and  quoting of target names, respectively. Implementors are strongly encouraged to
       use these characters only for these purposes.

       A request was made to extend the suffix delimiter  character  from  a  <period>  to  any  character.  The
       metarules  feature  in newer makes solves this problem in a more general way. This volume of POSIX.1‐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

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

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

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

       Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1, 2013 Edition,
       Standard  for  Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electrical and Electronics Engineers,  Inc
       and  The  Open Group.  (This is POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) 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.unix.org/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 .