make(1p) - phpMan

MAKE(1P)                   POSIX Programmer's Manual                  MAKE(1P)

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  (DEVELOP-
       MENT)
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  corre-
       sponding 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 prerequi-
       sites) from which they are derived. A description file (makefile)  con-
       tains  a  description  of the relationships between files, and the com-
       mands 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 infer-
       ence rules that infer prerequisite relationships  to  simplify  mainte-
       nance 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  condi-
       tions are not met.
OPTIONS
       The  make  utility  shall  conform  to  the  Base Definitions volume of
       IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
       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 path-
              name 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  cur-
              rent  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;  oth-
              erwise,  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  prereq-
              uisites.
       -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  asso-
              ciated  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 tar-
              get 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  con-
       taining  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
              IEEE Std 1003.1-2001, Section  8.2,  Internationalization  Vari-
              ables  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  repre-
              senting  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 hyphens
                 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
                 hyphens and <blank>-separated as described in the Base  Defi-
                 nitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility
                 Syntax Guidelines.  The macro= value macro  definition  oper-
                 ands  can  also  be included. The difference between the con-
                 tents of MAKEFLAGS and the make utility command line is  that
                 the  contents  of  the variable shall not be subjected to the
                 word expansions (see Word Expansions ) associated with  pars-
                 ing 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  subdi-
              rectory 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 make-
       file 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 sig-
       nals.
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  out-
       put  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  them-
       selves 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 corre-
       sponding 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 ), and com-
       ments. 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 sys-
       tems, 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 '-' argu-
       ment 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.
       When an escaped <newline> (one preceded by a backslash) is  found  any-
       where  in  the makefile except in a command 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>.
   Makefile Execution
       Makefile command lines shall be processed one at a time by writing  the
       makefile  command line to the standard output (unless one of the condi-
       tions listed under '@' suppresses the writing) and executing  the  com-
       mand(s)  in  the line. A <tab> may precede the command to standard out-
       put. Command execution shall be as if the makefile  command  line  were
       the  argument to the system() function. 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.
       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. When  a  com-
       mand is written to standard output, the prefix shall not be included in
       the output.
       -      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.

   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  exe-
       cuted  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 con-
       sisting solely of periods, underscores, digits,  and  alphabetics  from
       the  portable  character  set  (see  the  Base  Definitions  volume  of
       IEEE Std 1003.1-2001, Section 6.1, Portable Character Set). Implementa-
       tions  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 prerequi-
              sites. 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. Subse-
              quent 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 speci-
              fied 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 occur-
              rences 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  speci-
              fied  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  automati-
       cally  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 equal
       sign, up to a comment character ( '#' ) or an unescaped <newline>.  Any
       <blank>s immediately before or after the equal sign shall be ignored.
       Applications  shall  select macro names from the set of characters con-
       sisting solely of periods, underscores, digits,  and  alphabetics  from
       the  portable  character  set  (see  the  Base  Definitions  volume  of
       IEEE Std 1003.1-2001, 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 fol-
       lows:
        * 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 charac-
       ter. 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 occur-
       rences 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 evalu-
       ated 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 inter-
           nal  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  defini-
       tions  from  a  lower-numbered  source. Macro definitions from a single
       source (for example, the make utility command line, the MAKEFLAGS envi-
       ronment  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  defini-
       tions (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  MAKE-
       FLAGS  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 vari-
       ables 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 slashes or periods.) 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 prereq-
       uisites 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>s 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 suf-
       fixes. 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  prereq-
       uisite  with a suffix .s2 is specified as a target .s2.s1. The internal
       macros provide the means to specify general inference rules (see Inter-
       nal 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  com-
       pared  to  the list of suffixes specified by the .SUFFIXES special tar-
       gets. 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 defini-
       tion  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  cur-
       rent 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 mem-
       ber 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 prereq-
       uisites 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 accom-
       plished 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 appro-
          priate 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 tar-
              get.  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), $% rep-
       resents 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  file-
              name 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  direc-
       tory. 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 exten-
       sions.
       The -k and -S options are both present so that the relationship between
       the  command line, the MAKEFLAGS variable, and the makefile can be con-
       trolled 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 vari-
       able, 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 fea-
       tures provided by other parts of this volume  of  IEEE Std 1003.1-2001.
       The default rules include rules for optional commands in this volume of
       IEEE Std 1003.1-2001. Only rules pertaining to commands that  are  pro-
       vided 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 = value1NEW   = $(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. Conform-
       ing applications do not do this, although some  backwards-compatibility
       support may be included in some implementations.
       The  following characters in filenames may give trouble: '=', ':', '`',
       '", and '@' . 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>s throughout the makefile is histori-
       cal 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  IEEE Std 1003.1-2001  is
       intended  to  provide  the means for changing portable source code into
       executables that can be run on an IEEE Std 1003.1-2001-conforming  sys-
       tem.  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 Sys-
          tem 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 spaces as well as tabs 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 oth-
          ers)
       Additionally, many vendors and research  organizations  have  rethought
       the  basic  concepts of make, creating vastly extended, as well as com-
       pletely new, syntaxes. Each of these  versions  of  make  fulfills  the
       needs  of  a  different community of users; it is unreasonable for this
       volume of IEEE Std 1003.1-2001 to require behavior that would be incom-
       patible  (and probably inferior) to historical practice for such a com-
       munity.
       In similar circumstances, when the  industry  has  enough  sufficiently
       incompatible  formats  as  to  make them irreconcilable, this volume of
       IEEE Std 1003.1-2001 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 make-
       file 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 differ-
       ent 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 exten-
       sions as SCCS/s.Makefile and other variations. It was made an implemen-
       tation-defined  requirement  (as  opposed  to  unspecified behavior) to
       highlight surprising implementations that might select something  unex-
       pected  like  /etc/Makefile.  XSI-conformant systems also try ./s.make-
       file, 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  IEEE Std 1003.1-2001,  but
       could be provided as a compatible extension. The macro PARALLEL is used
       by some historical systems with essentially the same meaning (but with-
       out 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  IEEE Std 1003.1-2001  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 "pre-
       ferred" 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-imple-
       mentation issue as to whether c99 is as valuable as cc.
       The  -d option to make is frequently used to produce debugging informa-
       tion, but is too  implementation-defined  to  add  to  this  volume  of
       IEEE Std 1003.1-2001.
       The -p option is not passed in MAKEFLAGS on most historical implementa-
       tions 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  com-
       mand  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  situa-
       tion.  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 pri-
       mary 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 fea-
       tures   provided   by   other    portions    of    this    volume    of
       IEEE Std 1003.1-2001.   The  default  rules  include rules for optional
       commands in this volume of IEEE Std 1003.1-2001. 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 IEEE Std 1003.1-2001. 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 com-
       mands. 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  pre-
       requisites  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. Implementa-
       tions 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>s. A  conform-
       ing  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  glob-
       ally  (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 conse-
       quences.  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  typi-
       cally 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 com-
       mand lines for a target and execute them using a single  shell  invoca-
       tion;  the System V method is to pass each line individually to a sepa-
       rate shell. The single-shell method has the advantages  in  performance
       and  the  lack of a requirement for many continued lines. However, con-
       verting to this newer method has caused portability problems with  many
       historical makefiles, so the behavior with the POSIX makefile is speci-
       fied to be the same as that of System V. It is suggested that the  spe-
       cial 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>s and <space>s on terminals or  printed  list-
       ings, confusing bugs can arise. In early proposals, an attempt was made
       to correct this problem by allowing leading <blank>s instead of <tab>s.
       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  spaces
       before  macro definitions. Forcing macro lines into column 1 would be a
       significant backwards-compatibility problem for some makefiles.  There-
       fore, historical practice was restored.
       The  System  V  INCLUDE  feature was considered, but not included. This
       would treat a line that began in the first column and contained INCLUDE
       <filename>  as  an  indication  to read <filename> at that point in the
       makefile. This is difficult to use in a portable  way,  and  it  raises
       concerns  about nesting levels and diagnostics. System V, BSD, GNU, and
       others have used different methods for including files.
       The System V dynamic dependency feature was not included. It would sup-
       port:

              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 avail-
       able from some vendors, but it would cause too  many  changes  to  this
       make to support. It would have introduced rule chaining and new substi-
       tution 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.  Imple-
       mentors  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 IEEE Std 1003.1-2001
       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 gener-
       ally  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  tar-
       gets  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 lat-
       ter case has no traditional meaning and is reserved for  implementation
       extensions, such as in GNU make.
FUTURE DIRECTIONS
       None.
SEE ALSO
       Shell  Command  Language, ar, c99, get, lex, sccs, sh, yacc, the System
       Interfaces volume of IEEE Std 1003.1-2001, exec, system()
COPYRIGHT
       Portions of this text are reprinted and reproduced in  electronic  form
       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
       Specifications  Issue  6,  Copyright  (C) 2001-2003 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 .

IEEE/The Open Group                  2003                             MAKE(1P)