GNU.WIKI: The GNU/Linux Knowledge Base

  [HOME] [PHP Manual] [HowTo] [ABS] [MAN1] [MAN2] [MAN3] [MAN4] [MAN5] [MAN6] [MAN7] [MAN8] [MAN9]

  [0-9] [Aa] [Bb] [Cc] [Dd] [Ee] [Ff] [Gg] [Hh] [Ii] [Jj] [Kk] [Ll] [Mm] [Nn] [Oo] [Pp] [Qq] [Rr] [Ss] [Tt] [Uu] [Vv] [Ww] [Xx] [Yy] [Zz]


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
       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
              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
              IEEE Std 1003.1-2001,    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 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
                 Definitions volume  of  IEEE Std 1003.1-2001,  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 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  ),  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.

       When  an  escaped  <newline>  (one  preceded  by  a backslash) is found
       anywhere 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
       conditions  listed  under '@' suppresses the writing) and executing the
       command(s) in the line. A <tab> may precede  the  command  to  standard
       output. 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
       command 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
       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
       IEEE Std 1003.1-2001,    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 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
       consisting 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
       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 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
       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>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
       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
       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 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.
       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: '=' , ':' , '`'
       , '" , 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
       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 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
       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 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
          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  IEEE Std 1003.1-2001  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
       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
       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 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
       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 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
       "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
       IEEE Std 1003.1-2001.

       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
       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
       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>s.  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:

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


       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>s  and  <space>s  on  terminals  or  printed
       listings, 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. Therefore, 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
       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 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
       generally useful to programs. In historical implementations the  output
       is not suitable for use in generating makefiles. The -p format has been
       variable across historical implementations. Therefore,  the  definition
       of  -p  was  only  to provide a consistently named option for obtaining
       make script debugging information.

       Some historical implementations have not cleared the suffix  list  with
       -r.

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

       Empty  inference  rules  are  specified with a semicolon command rather
       than omitting all commands, as described  in  an  early  proposal.  The
       latter   case   has   no   traditional  meaning  and  is  reserved  for
       implementation extensions, such as in GNU make.

FUTURE DIRECTIONS

       None.

SEE ALSO

       Shell Command Language , ar , 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.php .



  All copyrights belong to their respective owners. Other content (c) 2014-2018, GNU.WIKI. Please report site errors to webmaster@gnu.wiki.
Page load time: 0.114 seconds. Last modified: November 04 2018 12:49:43.