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



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


NNAAMMEE
       make -- maintain, update, and regenerate groups of programs
       (DDEEVVEELLOOPPMMEENNTT)

SSYYNNOOPPSSIISS
       make [[-einpqrst]] [[-f _m_a_k_e_f_i_l_e]]... [[-k|-S]] [[_m_a_c_r_o=_v_a_l_u_e...]]
           [[_t_a_r_g_e_t___n_a_m_e...]]

DDEESSCCRRIIPPTTIIOONN
       The _m_a_k_e 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 _m_a_k_e 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. _I_n_f_e_r_e_n_c_e _r_u_l_e_s, which have one target name with at least one
           <period> (''..'')  and no <slash> (''//'')

        2. _T_a_r_g_e_t _r_u_l_e_s, which can have more than one target name

       In addition, _m_a_k_e 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 ..PPOOSSIIXX

        *  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 _m_a_k_e is unspecified if either or both of these
       conditions are not met.

OOPPTTIIOONNSS
       The _m_a_k_e utility shall conform to the Base Definitions volume of
       POSIX.1-2008, _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s, except for
       Guideline 9.

       The following options shall be supported:

       --ee        Cause environment variables, including those with null
                 values, to override macro assignments within makefiles.

       --ff _m_a_k_e_f_i_l_e
                 Specify a different makefile. The argument _m_a_k_e_f_i_l_e is a
                 pathname of a description file, which is also referred to as
                 the _m_a_k_e_f_i_l_e.  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.

       --ii        Ignore error codes returned by invoked commands. This mode is
                 the same as if the special target ..IIGGNNOORREE were specified
                 without prerequisites.

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

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

       --pp        Write to standard output the complete set of macro
                 definitions and target descriptions. The output format is
                 unspecified.

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

       --rr        Clear the suffix list and do not use the built-in rules.

       --SS        Terminate _m_a_k_e if an error occurs while executing the
                 commands to bring a target up-to-date. This shall be the
                 default and the opposite of --kk.

       --ss        Do not write makefile command lines or touch messages (see
                 --tt) to standard output before executing. This mode shall be
                 the same as if the special target ..SSIILLEENNTT were specified
                 without prerequisites.

       --tt        Update the modification time of each target as though a _t_o_u_c_h
                 _t_a_r_g_e_t had been executed. Targets that have prerequisites but
                 no commands (see _T_a_r_g_e_t _R_u_l_e_s), 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 _m_a_k_e_f_i_l_e
                 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 _M_A_K_E_F_L_A_G_S environment variable shall be
       evaluated before any options specified on the _m_a_k_e utility command
       line. If the --kk and --SS options are both specified on the _m_a_k_e utility
       command line or by the _M_A_K_E_F_L_A_G_S environment variable, the last option
       specified shall take precedence.  If the --ff or --pp options appear in the
       _M_A_K_E_F_L_A_G_S environment variable, the result is undefined.

OOPPEERRAANNDDSS
       The following operands shall be supported:

       _t_a_r_g_e_t___n_a_m_e
                 Target names, as defined in the EXTENDED DESCRIPTION section.
                 If no target is specified, while _m_a_k_e is processing the
                 makefiles, the first target that _m_a_k_e encounters that is not
                 a special target or an inference rule shall be used.

       _m_a_c_r_o=_v_a_l_u_e
                 Macro definitions, as defined in _M_a_c_r_o_s.

       If the _t_a_r_g_e_t___n_a_m_e and _m_a_c_r_o=_v_a_l_u_e operands are intermixed on the _m_a_k_e
       utility command line, the results are unspecified.

SSTTDDIINN
       The standard input shall be used only if the _m_a_k_e_f_i_l_e option-argument
       is ''--''.  See the INPUT FILES section.

IINNPPUUTT FFIILLEESS
       The input file, otherwise known as the makefile, is a text file
       containing rules, macro definitions, and comments. See the EXTENDED
       DESCRIPTION section.

EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS
       The following environment variables shall affect the execution of _m_a_k_e:

       _L_A_N_G      Provide a default value for the internationalization
                 variables that are unset or null. (See the Base Definitions
                 volume of POSIX.1-2008, _S_e_c_t_i_o_n _8_._2, _I_n_t_e_r_n_a_t_i_o_n_a_l_i_z_a_t_i_o_n
                 _V_a_r_i_a_b_l_e_s for the precedence of internationalization
                 variables used to determine the values of locale categories.)

       _L_C___A_L_L    If set to a non-empty string value, override the values of
                 all the other internationalization variables.

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

       _L_C___M_E_S_S_A_G_E_S
                 Determine the locale that should be used to affect the format
                 and contents of diagnostic messages written to standard
                 error.

       _M_A_K_E_F_L_A_G_S
                 This variable shall be interpreted as a character string
                 representing a series of option characters to be used as the
                 default options. The implementation shall accept both of the
                 following formats (but need not accept them when intermixed):

                  *  The characters are option letters without the leading
                     <hyphen> characters or <blank> separation used on a _m_a_k_e
                     utility command line.

                  *  The characters are formatted in a manner similar to a
                     portion of the _m_a_k_e utility command line: options are
                     preceded by <hyphen> characters and <blank>-separated as
                     described in the Base Definitions volume of POSIX.1-2008,
                     _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s.  The _m_a_c_r_o=_v_a_l_u_e
                     macro definition operands can also be included. The
                     difference between the contents of _M_A_K_E_F_L_A_G_S and the _m_a_k_e
                     utility command line is that the contents of the variable
                     shall not be subjected to the word expansions (see
                     _S_e_c_t_i_o_n _2_._6, _W_o_r_d _E_x_p_a_n_s_i_o_n_s) associated with parsing the
                     command line values.

       _N_L_S_P_A_T_H   Determine the location of message catalogs for the processing
                 of _L_C___M_E_S_S_A_G_E_S.

       _P_R_O_J_E_C_T_D_I_R
                 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
                 SSCCCCSS in the identified directory. If the value of _P_R_O_J_E_C_T_D_I_R
                 begins with a <slash>, it shall be considered an absolute
                 pathname; otherwise, the value of _P_R_O_J_E_C_T_D_I_R is treated as a
                 user name and that user's initial working directory shall be
                 examined for a subdirectory ssrrcc or ssoouurrccee.  If such a
                 directory is found, it shall be used. Otherwise, the value is
                 used as a relative pathname.

                 If _P_R_O_J_E_C_T_D_I_R is not set or has a null value, the search for
                 SCCS files shall be made in the directory SSCCCCSS in the current
                 directory.

                 The setting of _P_R_O_J_E_C_T_D_I_R affects all files listed in the
                 remainder of this utility description for files with a
                 component named SSCCCCSS.

       The value of the _S_H_E_L_L environment variable shall not be used as a
       macro and shall not be modified by defining the SSHHEELLLL 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 _M_a_c_r_o_s.

AASSYYNNCCHHRROONNOOUUSS EEVVEENNTTSS
       If not already ignored, _m_a_k_e 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 ..PPRREECCIIOOUUSS or
       unless one of the --nn, --pp, or --qq 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, _m_a_k_e shall take the standard action for all other
       signals.

SSTTDDOOUUTT
       The _m_a_k_e utility shall write all commands to be executed to standard
       output unless the --ss option was specified, the command is prefixed with
       an at-sign, or the special target ..SSIILLEENNTT has either the current target
       as a prerequisite or has no prerequisites. If _m_a_k_e 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 --tt option is present
       and a file is touched, _m_a_k_e shall write to standard output a message of
       unspecified format indicating that the file was touched, including the
       filename of the file.

SSTTDDEERRRR
       The standard error shall be used only for diagnostic messages.

OOUUTTPPUUTT FFIILLEESS
       Files can be created when the --tt option is present. Additional files
       can also be created by the utilities invoked by _m_a_k_e.

EEXXTTEENNDDEEDD DDEESSCCRRIIPPTTIIOONN
       The _m_a_k_e 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 _m_a_k_e 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 _m_a_k_e utility
       shall use the modification times of files to determine whether the
       corresponding targets are out-of-date.

       After _m_a_k_e 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.

   MMaakkeeffiillee SSyynnttaaxx
       A makefile can contain rules, macro definitions (see _M_a_c_r_o_s), include
       lines, and comments. There are two kinds of rules: _i_n_f_e_r_e_n_c_e _r_u_l_e_s and
       _t_a_r_g_e_t _r_u_l_e_s.  The _m_a_k_e utility shall contain a set of built-in
       inference rules. If the --rr 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 _M_a_c_r_o_s.  Comments start with a <number-sign>
       (''##'') and continue until an unescaped <newline> is reached.

       By default, the following files shall be tried in sequence: ..//mmaakkeeffiillee
       and ..//MMaakkeeffiillee.  If neither ..//mmaakkeeffiillee or ..//MMaakkeeffiillee are found, other
       implementation-defined files may also be tried.  On XSI-conformant
       systems, the additional files ..//ss..mmaakkeeffiillee, SSCCCCSS//ss..mmaakkeeffiillee,
       ..//ss..MMaakkeeffiillee, and SSCCCCSS//ss..MMaakkeeffiillee shall also be tried.

       The --ff option shall direct _m_a_k_e 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 _m_a_k_e_f_i_l_e is used to refer to any rules provided by the user,
       whether in ..//mmaakkeeffiillee or its variants, or specified by the --ff option.

       The rules in makefiles shall consist of the following types of lines:
       target rules, including special targets (see _T_a_r_g_e_t _R_u_l_e_s), inference
       rules (see _I_n_f_e_r_e_n_c_e _R_u_l_e_s), macro definitions (see _M_a_c_r_o_s), empty
       lines, and comments.

       Target and Inference Rules may contain _c_o_m_m_a_n_d _l_i_n_e_s.  Command lines
       can have a prefix that shall be removed before execution (see _M_a_k_e_f_i_l_e
       _E_x_e_c_u_t_i_o_n).

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

   IInncclluuddee LLiinneess
       If the word iinncclluuddee appears at the beginning of a line and is followed
       by one or more <blank> characters, the string formed by the remainder
       of the line shall be processed as follows to produce a pathname:

        *  The trailing <newline> and any comment shall be discarded. If the
           resulting string contains any double-quote characters (''""'') the
           behavior is unspecified.

        *  The resulting string shall be processed for macro expansion (see
           _M_a_c_r_o_s.

        *  Any <blank> characters that appear after the first non-<blank>
           shall be used as separators to divide the macro-expanded string
           into fields. It is unspecified whether any other white-space
           characters are also used as separators. It is unspecified whether
           pathname expansion (see _S_e_c_t_i_o_n _2_._1_3, _P_a_t_t_e_r_n _M_a_t_c_h_i_n_g _N_o_t_a_t_i_o_n) is
           also performed.

        *  If the processing of separators and optional pathname expansion
           results in either zero or two or more non-empty fields, the
           behavior is unspecified. If it results in one non-empty field, that
           field is taken as the pathname.

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

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

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

   MMaakkeeffiillee EExxeeccuuttiioonn
       Makefile command lines shall be processed one at a time.

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

       -     If the command prefix contains a <hyphen>, or the --ii option is
             present, or the special target ..IIGGNNOORREE 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 _m_a_k_e utility
             command line --nn option is not specified, or the --ss option is
             present, or the special target ..SSIILLEENNTT 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 --nn, --qq, or
             --tt is specified.

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

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

   TTaarrggeett RRuulleess
       Target rules are formatted as follows:

           _t_a_r_g_e_t [[_t_a_r_g_e_t...]]: [[_p_r_e_r_e_q_u_i_s_i_t_e...]][[;;_c_o_m_m_a_n_d]]
           [[<tab>_c_o_m_m_a_n_d
           <tab>_c_o_m_m_a_n_d
           ...]]

           _l_i_n_e _t_h_a_t _d_o_e_s _n_o_t _b_e_g_i_n _w_i_t_h <tab>

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

       Applications shall select target names from the set of characters
       consisting solely of periods, underscores, digits, and alphabetics from
       the portable character set (see the Base Definitions volume of
       POSIX.1-2008, _S_e_c_t_i_o_n _6_._1, _P_o_r_t_a_b_l_e _C_h_a_r_a_c_t_e_r _S_e_t).  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 _s_p_e_c_i_a_l _t_a_r_g_e_t_s
       and control the operation of _m_a_k_e:

       ..DDEEFFAAUULLTT  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 _m_a_k_e if there
                 are no other rules available to build a target.

       ..IIGGNNOORREE   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 --ii option.
                 Subsequent occurrences of ..IIGGNNOORREE shall add to the list of
                 targets ignoring command errors. If no prerequisites are
                 specified, _m_a_k_e shall behave as if the --ii option had been
                 specified and errors from all commands associated with all
                 targets shall be ignored.

       ..PPOOSSIIXX    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, _m_a_k_e shall
                 process the makefile as specified by this section; otherwise,
                 the behavior of _m_a_k_e is unspecified.

       ..PPRREECCIIOOUUSS Prerequisites of this special target shall not be removed if
                 _m_a_k_e receives one of the asynchronous events explicitly
                 described in the ASYNCHRONOUS EVENTS section. Subsequent
                 occurrences of ..PPRREECCIIOOUUSS 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 ..PPRREECCIIOOUUSS.

       ..SSCCCCSS__GGEETT 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 _D_e_f_a_u_l_t _R_u_l_e_s).  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, _m_a_k_e 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, _m_a_k_e
                 shall assume that that file is up-to-date. If, however, an
                 SCCS file named SSCCCCSS//ss.._s_o_u_r_c_e___f_i_l_e is found for a target
                 _s_o_u_r_c_e___f_i_l_e, _m_a_k_e compares the timestamp of the target file
                 with that of the SSCCCCSS//ss..ssoouurrccee__ffiillee to ensure the target is
                 up-to-date. If the target is missing, or if the SCCS file is
                 newer, _m_a_k_e shall automatically issue the commands specified
                 for the ..SSCCCCSS__GGEETT special target to retrieve the most recent
                 version. However, if the target is writable by anyone, _m_a_k_e
                 shall not retrieve a new version.

       ..SSIILLEENNTT   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 ..SSIILLEENNTT shall add to the list of
                 targets with silent commands. If no prerequisites are
                 specified, _m_a_k_e shall behave as if the --ss option had been
                 specified and no commands or touch messages associated with
                 any target shall be written to standard output.

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

       The special targets ..IIGGNNOORREE, ..PPOOSSIIXX, ..PPRREECCIIOOUUSS, ..SSIILLEENNTT, and ..SSUUFFFFIIXXEESS
       shall be specified without commands.

       Targets with names consisting of a leading <period> followed by the
       uppercase letters ""PPOOSSIIXX"" 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.

   MMaaccrrooss
       Macro definitions are in the form:

           _s_t_r_i_n_g_1 = [[_s_t_r_i_n_g_2]]

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

       Applications shall select macro names from the set of characters
       consisting solely of periods, underscores, digits, and alphabetics from
       the portable character set (see the Base Definitions volume of
       POSIX.1-2008, _S_e_c_t_i_o_n _6_._1, _P_o_r_t_a_b_l_e _C_h_a_r_a_c_t_e_r _S_e_t).  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 $(_s_t_r_i_n_g_1) or ${_s_t_r_i_n_g_1} shall be replaced by _s_t_r_i_n_g_2, 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 _s_t_r_i_n_g_1 is a single
       character. The macro $$ shall be replaced by the single character ''$$''.
       If _s_t_r_i_n_g_1 in a macro expansion contains a macro expansion, the results
       are unspecified.

       Macro expansions using the forms $(_s_t_r_i_n_g_1[[::_s_u_b_s_t_1==[[_s_u_b_s_t_2]]]]) or
       ${_s_t_r_i_n_g_1[[::_s_u_b_s_t_1==[[_s_u_b_s_t_2]]]]} can be used to replace all occurrences of
       _s_u_b_s_t_1 with _s_u_b_s_t_2 when the macro substitution is performed. The _s_u_b_s_t_1
       to be replaced shall be recognized when it is a suffix at the end of a
       word in _s_t_r_i_n_g_1 (where a _w_o_r_d, in this context, is defined to be a
       string delimited by the beginning of the line, a <blank>, or a
       <newline>).  If _s_t_r_i_n_g_1 in a macro expansion contains a macro
       expansion, the results are unspecified.

       Macro expansions in _s_t_r_i_n_g_1 of macro definition lines shall be
       evaluated when read. Macro expansions in _s_t_r_i_n_g_2 of macro definition
       lines shall be performed when the macro identified by _s_t_r_i_n_g_1 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 _m_a_k_e utility command line, in the order
           specified on the command line. It is unspecified whether the
           internal macros defined in _I_n_t_e_r_n_a_l _M_a_c_r_o_s are accepted from this
           source.

        2. Macros defined by the _M_A_K_E_F_L_A_G_S environment variable, in the order
           specified in the environment variable. It is unspecified whether
           the internal macros defined in _I_n_t_e_r_n_a_l _M_a_c_r_o_s are accepted from
           this source.

        3. The contents of the environment, excluding the _M_A_K_E_F_L_A_G_S and _S_H_E_L_L
           variables and including the variables with null values.

        4. Macros defined in the inference rules built into _m_a_k_e.

       Macro definitions from these sources shall not override macro
       definitions from a lower-numbered source. Macro definitions from a
       single source (for example, the _m_a_k_e utility command line, the
       _M_A_K_E_F_L_A_G_S 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 --ee 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 _m_a_k_e utility command line
       options (except --ff and --pp) and _m_a_k_e utility command line macro
       definitions (except any for the _M_A_K_E_F_L_A_G_S macro), not already included
       in the _M_A_K_E_F_L_A_G_S macro, shall be added to the _M_A_K_E_F_L_A_G_S macro, quoted
       in an implementation-defined manner such that when _M_A_K_E_F_L_A_G_S is read by
       another instance of the _m_a_k_e command, the original macro's value is
       recovered. Other implementation-defined options and macros may also be
       added to the _M_A_K_E_F_L_A_G_S macro. If this modifies the value of the
       _M_A_K_E_F_L_A_G_S macro, or, if the _M_A_K_E_F_L_A_G_S macro is modified at any
       subsequent time, the _M_A_K_E_F_L_A_G_S environment variable shall be modified
       to match the new value of the _M_A_K_E_F_L_A_G_S macro. The result of setting
       _M_A_K_E_F_L_A_G_S in the Makefile is unspecified.

       Before the makefile(s) are read, all of the _m_a_k_e utility command line
       macro definitions (except the _M_A_K_E_F_L_A_G_S macro or the _S_H_E_L_L macro) shall
       be added to the environment of _m_a_k_e.  Other implementation-defined
       variables may also be added to the environment of _m_a_k_e.

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

   IInnffeerreennccee RRuulleess
       Inference rules are formatted as follows:

           _t_a_r_g_e_t:
           <tab>_c_o_m_m_a_n_d
           [[<tab>_c_o_m_m_a_n_d]]
           ...

           _l_i_n_e _t_h_a_t _d_o_e_s _n_o_t _b_e_g_i_n _w_i_t_h <tab> _o_r #

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

       The application shall ensure that the makefile does not specify
       prerequisites for inference rules; no characters other than white space
       shall follow the <colon> in the first line, except when creating the
       _e_m_p_t_y _r_u_l_e_, 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:

           _r_u_l_e: ;

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

       The _m_a_k_e 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, _m_a_k_e contains a built-
       in set of inference rules. Additional rules can be specified in the
       makefile.

       The special target ..SSUUFFFFIIXXEESS 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 ..SSUUFFFFIIXXEESS special target in the makefile.
       A ..SSUUFFFFIIXXEESS target with no prerequisites shall clear the list of
       suffixes. An empty ..SSUUFFFFIIXXEESS target followed by a new ..SSUUFFFFIIXXEESS 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 ..ss11 from a
       prerequisite with a suffix ..ss22 is specified as a target ..ss22..ss11.  The
       internal macros provide the means to specify general inference rules
       (see _I_n_t_e_r_n_a_l _M_a_c_r_o_s).

       When no target rule is found to update a target, the inference rules
       shall be checked. The suffix of the target (..ss11) to be built is
       compared to the list of suffixes specified by the ..SSUUFFFFIIXXEESS special
       targets. If the ..ss11 suffix is found in ..SSUUFFFFIIXXEESS, the inference rules
       shall be searched in the order defined for the first ..ss22..ss11 rule whose
       prerequisite file ($$**..ss22) 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 ..ss22 is the
       definition of how to build _t_a_r_g_e_t from ttaarrggeett..ss22.  The other suffix
       (..ss11) is treated as null.

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

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

   IInntteerrnnaall MMaaccrrooss
       The _m_a_k_e 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 _t_a_r_g_e_t _r_u_l_e, _i_n_f_e_r_e_n_c_e
       _r_u_l_e, _t_a_r_g_e_t, and _p_r_e_r_e_q_u_i_s_i_t_e is necessary.

       Target rules are specified by the user in a makefile for a particular
       target. Inference rules are user-specified or _m_a_k_e-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 _t_a_r_g_e_t refers to one of:

        *  A target specified in the makefile

        *  An explicit prerequisite specified in the makefile that becomes the
           target when _m_a_k_e processes it during recursion

        *  An implicit prerequisite that becomes a target when _m_a_k_e processes
           it during recursion

       In the definitions that follow, the word _p_r_e_r_e_q_u_i_s_i_t_e 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 ..cc..aa inference rule, $@ represents the out-
               of-date ..aa file to be built. Similarly, in a makefile target
               rule to build lliibb..aa from ffiillee..cc, $@ represents the out-of-date
               lliibb..aa.

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

               For example, in a makefile target rule to build lliibb..aa(ffiillee..oo),
               $% represents ffiillee..oo, as opposed to $@, which represents lliibb..aa.

       $?      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 _p_r_o_g from
               ffiillee11..oo, ffiillee22..oo, and ffiillee33..oo, and where _p_r_o_g is not out-of-
               date with respect to ffiillee11..oo, but is out-of-date with respect
               to ffiillee22..oo and ffiillee33..oo, $? represents ffiillee22..oo and ffiillee33..oo.

       $<      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 ..DDEEFFAAUULLTT rule, the $< macro
               shall evaluate to the current target name. The meaning of the
               $< macro shall be otherwise unspecified.

               For example, in the ..cc..aa inference rule, $< represents the
               prerequisite ..cc 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 ..cc..aa inference rule, $*.o represents the
               out-of-date ..oo file that corresponds to the prerequisite ..cc
               file.

       Each of the internal macros has an alternative form. When an uppercase
       ''DD'' or ''FF'' is appended to any of the macros, the meaning shall be
       changed to the _d_i_r_e_c_t_o_r_y _p_a_r_t for ''DD'' and _f_i_l_e_n_a_m_e _p_a_r_t for ''FF''.  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 _l_i_b(_m_e_m_b_e_r..oo) and the ss22..aa rule, the internal macros
       shall be defined as:

       $<      _m_e_m_b_e_r..ss22

       $*      _m_e_m_b_e_r

       $@      _l_i_b

       $?      _m_e_m_b_e_r..ss22

       $%      _m_e_m_b_e_r..oo

   DDeeffaauulltt RRuulleess
       The default rules for _m_a_k_e 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 CCCC, CCFFLLAAGGSS, YYAACCCC,
       YYFFLLAAGGSS, LLEEXX, LLFFLLAAGGSS, LLDDFFLLAAGGSS, and the ..cc, ..yy, and ..ll inference rules.
       Implementations that do not support FORTRAN may omit FFCC, FFFFLLAAGGSS, and
       the ..ff inference rules. Implementations may provide additional macros
       and rules.

           _S_P_E_C_I_A_L _T_A_R_G_E_T_S

           .SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@

           .SUFFIXES: .o .c .y .l .a .sh .f .c~ .y~ .l~ .sh~ .f~

           _M_A_C_R_O_S

           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

           _S_I_N_G_L_E _S_U_F_F_I_X _R_U_L_E_S

           .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 $@

           _D_O_U_B_L_E _S_U_F_F_I_X _R_U_L_E_S

           .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

EEXXIITT SSTTAATTUUSS
       When the --qq option is specified, the _m_a_k_e 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 --qq option is not specified, the _m_a_k_e utility shall exit with
       one of the following values:

        0    Successful completion.

       >0    An error occurred.

CCOONNSSEEQQUUEENNCCEESS OOFF EERRRROORRSS
       Default.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       If there is a source file (such as ..//ssoouurrccee..cc) and there are two SCCS
       files corresponding to it (..//ss..ssoouurrccee..cc and ..//SSCCCCSS//ss..ssoouurrccee..cc), on XSI-
       conformant systems _m_a_k_e uses the SCCS file in the current directory.
       However, users are advised to use the underlying SCCS utilities (_a_d_m_i_n,
       _d_e_l_t_a, _g_e_t, and so on) or the _s_c_c_s 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 ..PPOOSSIIXX special
       target in order to guarantee that they are not affected by local
       extensions.

       The --kk and --SS options are both present so that the relationship between
       the command line, the _M_A_K_E_F_L_A_G_S variable, and the makefile can be
       controlled precisely. If the kk flag is passed in _M_A_K_E_F_L_A_G_S and a
       command is of the form:

           $$((MMAAKKEE)) --SS ffoooo

       then the default behavior is restored for the child _m_a_k_e.

       When the --nn option is specified, it is always added to _M_A_K_E_F_L_A_G_S.  This
       allows a recursive _m_a_k_e --nn _t_a_r_g_e_t to be used to see all of the action
       that would be taken to update _t_a_r_g_e_t.

       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:

           CCFFLLAAGGSS == ""--DD CCOOMMMMEENNTT__CCHHAARR==''##''""

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

       The best way to provide portable makefiles is to include all of the
       rules needed in the makefile itself. The rules provided use only
       features provided by other parts of this volume of POSIX.1-2008. The
       default rules include rules for optional commands in this volume of
       POSIX.1-2008. Only rules pertaining to commands that are provided are
       needed in an implementation's default set.

       Macros used within other macros are evaluated when the new macro is
       used rather than when the new macro is defined. Therefore:

           MMAACCRROO == _v_a_l_u_e_1
           NNEEWW   == $$((MMAACCRROO))
           MMAACCRROO == _v_a_l_u_e_2

           target:
               echo $(NEW)

       would produce _v_a_l_u_e_2 and not _v_a_l_u_e_1 since NNEEWW was not expanded until it
       was needed in the _e_c_h_o command line.

       Some historical applications have been known to intermix _t_a_r_g_e_t___n_a_m_e
       and _m_a_c_r_o_=_n_a_m_e operands on the command line, expecting that all of the
       macros are processed before any of the targets are dealt with.
       Conforming applications do not do this, although some backwards-
       compatibility support may be included in some implementations.

       The following characters in filenames may give trouble: ''=='', ''::'', ''``'',
       single-quote, and ''@@''.  In include filenames, pattern matching
       characters and ''""'' should also be avoided, as they may be treated as
       special by some implementations.

       For inference rules, the description of $< and $? seem similar.
       However, an example shows the minor difference. In a makefile
       containing:

           ffoooo..oo:: ffoooo..hh

       if ffoooo..hh is newer than ffoooo..oo, yet ffoooo..cc is older than ffoooo..oo, the built-
       in rule to make ffoooo..oo from ffoooo..cc is used, with $< equal to ffoooo..cc and $?
       equal to ffoooo..hh.  If ffoooo..cc is also newer than ffoooo..oo, $< is equal to
       ffoooo..cc and $? is equal to ffoooo..hh ffoooo..cc.

EEXXAAMMPPLLEESS
        1. The following command:

               mmaakkee

           makes the first target found in the makefile.

        2. The following command:

               mmaakkee jjuunnkk

           makes the target jjuunnkk.

        3. The following makefile says that ppggmm depends on two files, aa..oo and
           bb..oo, and that they in turn depend on their corresponding source
           files (aa..cc and bb..cc), and a common file iinnccll..hh:

               ppggmm:: aa..oo bb..oo
                   cc9999 aa..oo bb..oo --oo ppggmm
               aa..oo:: iinnccll..hh aa..cc
                   cc9999 --cc aa..cc
               bb..oo:: iinnccll..hh bb..cc
                   cc9999 --cc bb..cc

        4. An example for making optimized ..oo files from ..cc files is:

               ..cc..oo::
                   cc9999 --cc --OO $$**..cc

           or:

               ..cc..oo::
                   cc9999 --cc --OO $$<<

        5. The most common use of the archive interface follows. Here, it is
           assumed that the source files are all C-language source:

               lliibb:: lliibb((ffiillee11..oo)) lliibb((ffiillee22..oo)) lliibb((ffiillee33..oo))
                   @@eecchhoo lliibb iiss nnooww uupp--ttoo--ddaattee

           The ..cc..aa rule is used to make ffiillee11..oo, ffiillee22..oo, and ffiillee33..oo and
           insert them into lliibb.

           The treatment of escaped <newline> characters throughout the
           makefile is historical practice. For example, the inference rule:

               ..cc..oo\\
               ::

           works, and the macro:

               ff==  bbaarr bbaazz\\
                   bbiizz
               aa::
                   eecchhoo ====$$ff====

           echoes ""====bbaarr bbaazz bbiizz===="".

           If $? were:

               //uussrr//iinncclluuddee//ssttddiioo..hh //uussrr//iinncclluuddee//uunniissttdd..hh ffoooo..hh

           then $(?D) would be:

               //uussrr//iinncclluuddee //uussrr//iinncclluuddee ..

           and $(?F) would be:

               ssttddiioo..hh uunniissttdd..hh ffoooo..hh

        6. The contents of the built-in rules can be viewed by running:

               mmaakkee --pp --ff //ddeevv//nnuullll 22>>//ddeevv//nnuullll

RRAATTIIOONNAALLEE
       The _m_a_k_e utility described in this volume of POSIX.1-2008 is intended
       to provide the means for changing portable source code into executables
       that can be run on an POSIX.1-2008-conforming system. It reflects the
       most common features present in System V and BSD _m_a_k_es.

       Historically, the _m_a_k_e 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 ""$${{MMAAKKEE}}"" and
           ""$$((MMAAKKEE))"" are executed when the --nn option is specified (GNU and
           System V)

        *  Modifications of the meaning of internal macros when referencing
           libraries (BSD and others)

        *  Using a single instance of the shell for all of the command lines
           of the target (BSD and others)

        *  Allowing <space> characters as well as <tab> characters to delimit
           command lines (BSD)

        *  Adding C preprocessor-style ``include'' and ``ifdef'' constructs
           (System V, GNU, BSD, and others)

        *  Remote execution of command lines (Sprite and others)

        *  Specifying additional special targets (BSD, System V, and most
           others)

       Additionally, many vendors and research organizations have rethought
       the basic concepts of _m_a_k_e, creating vastly extended, as well as
       completely new, syntaxes. Each of these versions of _m_a_k_e fulfills the
       needs of a different community of users; it is unreasonable for this
       volume of POSIX.1-2008 to require behavior that would be incompatible
       (and probably inferior) to historical practice for such a community.

       In similar circumstances, when the industry has enough sufficiently
       incompatible formats as to make them irreconcilable, this volume of
       POSIX.1-2008 has followed one or both of two courses of action.
       Commands have been renamed (_c_k_s_u_m, _e_c_h_o, and _p_a_x) and/or command line
       options have been provided to select the desired behavior (_g_r_e_p, _o_d,
       and _p_a_x).

       Because the syntax specified for the _m_a_k_e utility is, by and large, a
       subset of the syntaxes accepted by almost all versions of _m_a_k_e, 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 _m_a_k_e
       --PP, to achieve the portable behavior. Therefore, the special target
       ..PPOOSSIIXX was added to the makefile, allowing users to specify
       ``standard'' behavior. This special target does not preclude extensions
       in the _m_a_k_e 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 ..PPOOSSIIXX special target in order to guarantee
       that they are not affected by local extensions.

       The portable version of _m_a_k_e 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 --nn option is specified, it is always added to _M_A_K_E_F_L_A_G_S.  This
       allows a recursive _m_a_k_e --nn _t_a_r_g_e_t to be used to see all of the action
       that would be taken to update _t_a_r_g_e_t.

       The definition of _M_A_K_E_F_L_A_G_S 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 _m_a_k_e 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 ..//mmaakkeeffiillee and ..//MMaakkeeffiillee is to allow such
       extensions as SSCCCCSS//ss..MMaakkeeffiillee 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 //eettcc//MMaakkeeffiillee.  XSI-conformant systems also try
       ..//ss..mmaakkeeffiillee, SSCCCCSS//ss..mmaakkeeffiillee, ..//ss..MMaakkeeffiillee, and SSCCCCSS//ss..MMaakkeeffiillee.

       Early proposals contained the macro NNPPRROOCC as a means of specifying that
       _m_a_k_e should use _n processes to do the work required. While this feature
       is a valuable extension for many systems, it is not common usage and
       could require other non-trivial extensions to makefile syntax. This
       extension is not required by this volume of POSIX.1-2008, but could be
       provided as a compatible extension. The macro PPAARRAALLLLEELL 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 NNPPRROOCC and/or PPAARRAALLLLEELL as
       extensions to _m_a_k_e.

       The default rules are based on System V. The default CCCC== value is _c_9_9
       instead of _c_c because this volume of POSIX.1-2008 does not standardize
       the utility named _c_c.  Thus, every conforming application would be
       required to define CCCC==_c_9_9 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 _c_9_9 options, no advantage is
       conferred in terms of what the script can do.  It is a quality-of-
       implementation issue as to whether _c_9_9 is as valuable as _c_c.

       The --dd option to _m_a_k_e is frequently used to produce debugging
       information, but is too implementation-defined to add to this volume of
       POSIX.1-2008.

       The --pp option is not passed in _M_A_K_E_F_L_A_G_S 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
       --nn option is present. Based on the GNU version of _m_a_k_e, the behavior of
       --nn when the <plus-sign> prefix is encountered has been extended to
       apply to --qq and --tt as well. However, the System V convention of forcing
       command execution with --nn when the command line of a target contains
       either of the strings ""$$((MMAAKKEE))"" or ""$${{MMAAKKEE}}"" 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:

           ssuubbddiirr::
               ccdd ssuubbddiirr;; rrmm aallll__tthhee__ffiilleess;; $$((MMAAKKEE))

       The loss of the System V behavior in this case is well-balanced by the
       safety afforded to other makefiles that were not aware of this
       situation. In any event, the command line <plus-sign> prefix can
       provide the desired functionality.

       The double <colon> in the target rule format is supported in BSD
       systems to allow more than one target line containing the same target
       name to have commands associated with it. Since this is not
       functionality described in the SVID or XPG3 it has been allowed as an
       extension, but not mandated.

       The default rules are provided with text specifying that the built-in
       rules shall be the same as if the listed set were used. The intent is
       that implementations should be able to use the rules without change,
       but will be allowed to alter them in ways that do not affect the
       primary behavior.

       The best way to provide portable makefiles is to include all of the
       rules needed in the makefile itself. The rules provided use only
       features provided by other portions of this volume of POSIX.1-2008. The
       default rules include rules for optional commands in this volume of
       POSIX.1-2008. Only rules pertaining to commands that are provided are
       needed in the default set of an implementation.

       One point of discussion was whether to drop the default rules list from
       this volume of POSIX.1-2008. They provide convenience, but do not
       enhance portability of applications. The prime benefit is in
       portability of users who wish to type _m_a_k_e _c_o_m_m_a_n_d and have the command
       build from a ccoommmmaanndd..cc file.

       The historical _M_A_K_E_S_H_E_L_L feature was omitted. In some implementations
       it is used to let a user override the shell to be used to run _m_a_k_e
       commands. This was confusing; for a portable _m_a_k_e, the shell should be
       chosen by the makefile writer or specified on the _m_a_k_e command line and
       not by a user running _m_a_k_e.

       The _m_a_k_e 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 _y_a_c_c programs; for example:

           ffoooo:: yy..ttaabb..oo lleexx..oo mmaaiinn..oo
               $$((CCCC)) $$((CCFFLLAAGGSS)) --oo $$@ tt..ttaabb..oo lleexx..oo mmaaiinn..oo

       In this example, if _m_a_k_e chose any arbitrary order, the lleexx..oo might not
       be made with the correct yy..ttaabb..hh.  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 _m_a_k_e 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 _m_a_k_es allow blank, empty, or comment lines
       within the collection of commands marked by leading <tab> characters. A
       conforming makefile must ensure that each command starts with a <tab>,
       but implementations are free to ignore blank, empty, and comment lines
       without triggering the start of a new entry.

       The ASYNCHRONOUS EVENTS section includes having SIGTERM and SIGHUP,
       along with the more traditional SIGINT and SIGQUIT, remove the current
       target unless directed not to do so. SIGTERM and SIGHUP were added to
       parallel other utilities that have historically cleaned up their work
       as a result of these signals. When _m_a_k_e 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 ccoorree
       files upon receipt of SIGQUIT, the ccoorree from _m_a_k_e would conflict with a
       ccoorree 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 _m_a_k_e is rerun.

       The ..PPRREECCIIOOUUSS special target was extended to affect all targets
       globally (by specifying no prerequisites). The ..IIGGNNOORREE and ..SSIILLEENNTT
       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
       _m_a_k_e in System V were made to match historical practice from the BSD
       _m_a_k_e.

       Macros are not exported to the environment of commands to be run. This
       was never the case in any historical _m_a_k_e and would have serious
       consequences. The environment is the same as the environment to _m_a_k_e
       except that _M_A_K_E_F_L_A_G_S and macros defined on the _m_a_k_e command line are
       added.

       Some implementations do not use _s_y_s_t_e_m() 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
       _e_x_e_c_v_e().  There is no requirement that _s_y_s_t_e_m() be used specifically,
       but merely that the same results be achieved.  The metacharacters
       typically used to bypass the direct _e_x_e_c_v_e() execution have been any
       of:

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

       The default in some advanced versions of _m_a_k_e 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 ..OONNEESSHHEELLLL be used as an
       implementation extension to achieve the single-shell grouping for a
       target or group of targets.

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

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

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

           ccaatt:: $$$$@@..cc

       that would expand to;

           ccaatt:: ccaatt..cc

       This feature exists only in the new version of System V _m_a_k_e 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 _m_a_k_e.  This
       would make %%..oo:: %%..cc the same as ..cc..oo::.  This is quite useful and
       available from some vendors, but it would cause too many changes to
       this _m_a_k_e 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 _m_a_k_es solves
       this problem in a more general way. This volume of POSIX.1-2008 is
       staying with the more conservative historical definition.

       The standard output format for the --pp 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 --pp format has been
       variable across historical implementations. Therefore, the definition
       of --pp was only to provide a consistently named option for obtaining
       _m_a_k_e script debugging information.

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

       Implementations should be aware that some historical applications have
       intermixed _t_a_r_g_e_t___n_a_m_e and _m_a_c_r_o=_v_a_l_u_e 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 _m_a_k_e.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _C_h_a_p_t_e_r _2, _S_h_e_l_l _C_o_m_m_a_n_d _L_a_n_g_u_a_g_e, _a_r, _c_9_9, _g_e_t, _l_e_x, _s_c_c_s, _s_h, _y_a_c_c

       The Base Definitions volume of POSIX.1-2008, _S_e_c_t_i_o_n _6_._1, _P_o_r_t_a_b_l_e
       _C_h_a_r_a_c_t_e_r _S_e_t, _C_h_a_p_t_e_r _8, _E_n_v_i_r_o_n_m_e_n_t _V_a_r_i_a_b_l_e_s, _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y
       _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s

       The System Interfaces volume of POSIX.1-2008, _e_x_e_c, _s_y_s_t_e_m()

CCOOPPYYRRIIGGHHTT
       Portions of this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of
       Electrical and Electronics Engineers, Inc and The Open Group.  (This is
       POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
       event of any discrepancy between this version and the original IEEE and
       The Open Group Standard, the original IEEE and The Open Group Standard
       is the referee document. The original Standard can be obtained online
       at http://www.unix.org/online.html .

       Any typographical or formatting errors that appear in this page are
       most likely to have been introduced during the conversion of the source
       files to man page format. To report such errors, see
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2013                              MAKE(1)
