Man Pages

make(1p) - phpMan make(1p) - phpMan

Command: man perldoc info search(apropos)  


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 dif-
       fer (consult the corresponding Linux manual page for details of Linux behavior), or the interface  may  not  be
       implemented on Linux.

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

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

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

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


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


       In  addition, make shall have a collection of built-in macros and inference rules that infer prerequisite rela-
       tionships 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 for-
              mat 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  com-
       ments. 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  prece-
              dence 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  exam-
              ple, 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 writ-
              ten 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 direc-
              tory. If the value of PROJECTDIR begins with a slash, it shall be considered an absolute pathname;  oth-
              erwise,  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. Oth-
              erwise, 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  pre-
       requisite  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  modifica-
       tion 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 make-
       file 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 back-
       slash, 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 prerequi-
              site 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 exe-
              cuted 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  tar-
       get  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 com-
              mands, but without prerequisites. The commands shall be used by make if there are no other rules  avail-
              able to build a target.

       .IGNORE
              Prerequisites of this special target are targets themselves; this shall cause errors from commands asso-
              ciated 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  spe-
              cial 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 tar-
              get 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  make-
       file.  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  com-
       pares  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 immedi-
       ately 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  assign-
          ment 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 com-
       mand.

       Macro definitions shall be taken from the following sources, in the following logical order, before  the  make-
       file(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 vari-
       able, 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  defini-
       tions 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 util-
       ity 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 MAKE-
       FLAGS is read by another instance of the make command, the original macro's value is recovered. Other implemen-
       tation-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 vari-
       able  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  sin-
       gle-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  charac-
       ters  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 infer-
       ence 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 pre-
       fix, it is incompatible with make's suffix point of view.  Hence, the '~' is a way of changing any file  refer-
       ence 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-speci-
       fied or make-specified rules for a particular class of target name.  Explicit prerequisites are those prerequi-
       sites specified in a makefile on target lines. Implicit prerequisites are those prerequisites that  are  gener-
       ated  when inference rules are used.  Inference rules are applied to implicit prerequisites or to explicit pre-
       requisites 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  prereq-
       uisite  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  tar-
              get 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  pre-
       requisite .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. Implementa-
       tions 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 vari-
       able, 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 for-
       bidding something like:


              CFLAGS = "-D COMMENT_CHAR='#'"

       Many historical make utilities stop chaining together inference rules when an intermediate target  is  nonexis-
       tent.  For  example, it might be possible for a make to determine that both .y.c and .c.o could be used to con-
       vert 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 com-
       mands 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  implementa-
       tions.

       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  contain-
       ing:


              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-spe-
       cific 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 irrec-
       oncilable, 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 soft-
       ware 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 ./Make-
       file 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  his-
       torical  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  make-
       script  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 func-
       tionality.

       The  double colon in the target rule format is supported in BSD systems to allow more than one target line con-
       taining 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 pro-
       duce 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:


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

       The  default  in some advanced versions of make is to group all the command lines for a target and execute them
       using a single shell invocation; the System V method is to pass each line individually to a separate shell. The
       single-shell  method  has the advantages in performance and the lack of a requirement for many continued lines.
       However, converting to this newer method has caused portability problems with many historical makefiles, so the
       behavior with the POSIX makefile is specified to be the same as that of System V. It is suggested that the 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 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  sup-
       port.  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  fea-
       ture  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 suit-
       able for use in generating makefiles. The -p format has been variable across historical implementations. There-
       fore,  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, Stan-
       dard  for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifica-
       tions 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 Stan-
       dard, 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)