


      MMMMAAAAKKKKEEEE((((1111))))                     ((((UUUUNNNNIIIIXXXX 5555....2222))))                    MMMMAAAAKKKKEEEE((((1111))))



      NNNNAAAAMMMMEEEE
           make - maintain, update, and regenerate groups of programs

      SSSSYYYYNNNNTTTTAAAAXXXX
           mmmmaaaakkkkeeee [----ffff makefile] [----pppp] [----iiii] [----kkkk] [----ssss] [----rrrr] [----nnnn] [----bbbb] [----eeee]
           [----mmmm] [----tttt] [----dddd] [----qqqq] [names]

      DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
           The following is a brief description of all options and some
           special names:

           ----ffff _m_a_k_e_f_i_l_e  Description file name.  _M_a_k_e_f_i_l_e is assumed to
                        be the name of a description file.  A file name
                        of ---- denotes the standard input.  The contents
                        of _m_a_k_e_f_i_l_e override the built-in rules if they
                        are present.

           ----pppp           Print out the complete set of macro definitions
                        and target descriptions.

           ----iiii           Ignore error codes returned by invoked
                        commands.  This mode is entered if the fake
                        target name ....IIIIGGGGNNNNOOOORRRREEEE appears in the description
                        file.

           ----kkkk           Abandon work on the current entry, but continue
                        on other branches that do not depend on that
                        entry.

           ----ssss           Silent mode.  Do not print command lines before
                        executing.  This mode is also entered if the
                        fake target name ....SSSSIIIILLLLEEEENNNNTTTT appears in the
                        description file.

           ----rrrr           Do not use the built-in rules.

           ----nnnn           No execute mode.  Print commands, but do not
                        execute them.  Even lines beginning with an @@@@
                        are printed.

           ----bbbb           Compatibility mode for old makefiles.

           ----eeee           Environment variables override assignments
                        within makefiles.

           ----tttt           Touch the target files (causing them to be up-
                        to-date) rather than issue the usual commands.

           ----dddd           Debug mode.  Print out detailed information on
                        files and times examined.

           ----qqqq           Question.  The _m_a_k_e command returns a zero or



      Page 1                                                   (9010-E)






      MMMMAAAAKKKKEEEE((((1111))))                     ((((UUUUNNNNIIIIXXXX 5555....2222))))                    MMMMAAAAKKKKEEEE((((1111))))



                        non-zero status code depending on whether the
                        target file is or is not up-to-date.

           ....DDDDEEEEFFFFAAAAUUUULLLLTTTT     If a file must be made but there are no
                        explicit commands or relevant built-in rules,
                        the commands associated with the name ....DDDDEEEEFFFFAAAAUUUULLLLTTTT
                        are used if it exists.

           ....PPPPRRRREEEECCCCIIIIOOOOUUUUSSSS    Dependents of this target will not be removed
                        when quit or interrupt are hit.

           ....SSSSIIIILLLLEEEENNNNTTTT      Same effect as the ----ssss option.

           ....IIIIGGGGNNNNOOOORRRREEEE      Same effect as the ----iiii option.

           _M_a_k_e executes commands in _m_a_k_e_f_i_l_e to update one or more
           target _n_a_m_e_s.  _N_a_m_e is typically a program.  If no ----ffff option
           is present, mmmmaaaakkkkeeeeffffiiiilllleeee, MMMMaaaakkkkeeeeffffiiiilllleeee, ssss....mmmmaaaakkkkeeeeffffiiiilllleeee, and ssss....MMMMaaaakkkkeeeeffffiiiilllleeee
           are tried in order.  If _m_a_k_e_f_i_l_e is ----, the standard input is
           taken.  More than one ---- _m_a_k_e_f_i_l_e argument pair may appear.

           _M_a_k_e updates a target only if it depends on files that are
           newer than the target.  All prerequisite files of a target
           are added recursively to the list of targets.  Missing files
           are deemed to be out of date.

           _M_a_k_e_f_i_l_e contains a sequence of entries that specify
           dependencies.  The first line of an entry is a blank-
           separated, non-null list of targets, then a ::::, then a
           (possibly null) list of prerequisite files or dependencies.
           Text following a ;;;; and all following lines that begin with a
           tab are shell commands to be executed to update the target.
           The first line that does not begin with a tab or #### begins a
           new dependency or macro definition.  Shell commands may be
           continued across lines with the <backslash><new-line>
           sequence.  Everything printed by make (except the initial
           tab) is passed directly to the shell as is.  Thus,

                echo a\
                b

           will produce

                ab

           exactly the same as the shell would.

           Sharp (####) and new-line surround comments.

           The following _m_a_k_e_f_i_l_e says that ppppggggmmmm depends on two files
           aaaa....oooo and bbbb....oooo, and that they in turn depend on their
           corresponding source files (aaaa....cccc and bbbb....cccc) and a common file



      Page 2                                                   (9010-E)






      MMMMAAAAKKKKEEEE((((1111))))                     ((((UUUUNNNNIIIIXXXX 5555....2222))))                    MMMMAAAAKKKKEEEE((((1111))))



           iiiinnnnccccllll....hhhh:

                pgm: a.o b.o
                          cc a.o b.o -o pgm
                a.o: incl.h a.c
                          cc -c a.c
                b.o: incl.h b.c
                          cc -c b.c

           Command lines are executed one at a time, each by its own
           shell.  The first one or two characters in a command can be
           the following: ----, @@@@, ----@@@@, or @@@@----.  If @@@@ is present, printing
           of the command is suppressed.  If ---- is present, _m_a_k_e ignores
           an error.  A line is printed when it is executed unless the
           ----ssss option is present, or the entry ....SSSSIIIILLLLEEEENNNNTTTT:::: is in _m_a_k_e_f_i_l_e,
           or unless the initial character sequence contains a @@@@.  The
           ----nnnn option specifies printing without execution; however, if
           the command line has the string $$$$((((MMMMAAAAKKKKEEEE)))) in it, the line is
           always executed (see discussion of the MMMMAAAAKKKKEEEEFFFFLLLLAAAAGGGGSSSS macro under
           _E_n_v_i_r_o_n_m_e_n_t).  The ----tttt (touch) option updates the modified
           date of a file without executing any commands.

           Commands returning non-zero status normally terminate _m_a_k_e.
           If the ----iiii option is present, or the entry ....IIIIGGGGNNNNOOOORRRREEEE:::: appears
           in _m_a_k_e_f_i_l_e, or the initial character sequence of the
           command contains ----.  the error is ignored.  If the ----kkkk option
           is present, work is abandoned on the current entry, but
           continues on other branches that do not depend on that
           entry.

           The ----bbbb option allows old makefiles (those written for the
           old version of _m_a_k_e) to run without errors.  The difference
           between the old version of _m_a_k_e and this version is that
           this version requires all dependency lines to have a
           (possibly null or implicit) command associated with them.
           The previous version of _m_a_k_e assumed if no command was
           specified explicitly that the command was null.

           Interrupt and quit cause the target to be deleted unless the
           target is a dependency of the special name ....PPPPRRRREEEECCCCIIIIOOOOUUUUSSSS.

         EEEEnnnnvvvviiiirrrroooonnnnmmmmeeeennnntttt
           The environment is read by _m_a_k_e.  All variables are assumed
           to be macro definitions and processed as such.  The
           environment variables are processed before any makefile and
           after the internal rules; thus, macro assignments in a
           makefile override environment variables.  The ----eeee option
           causes the environment to override the macro assignments in
           a makefile.

           The MMMMAAAAKKKKEEEEFFFFLLLLAAAAGGGGSSSS environment variable is processed by _m_a_k_e as
           containing any legal input option (except ----ffff, ----pppp, and ----rrrr)



      Page 3                                                   (9010-E)






      MMMMAAAAKKKKEEEE((((1111))))                     ((((UUUUNNNNIIIIXXXX 5555....2222))))                    MMMMAAAAKKKKEEEE((((1111))))



           defined for the command line.  Further, upon invocation,
           _m_a_k_e ``invents'' the variable if it is not in the
           environment, puts the current options into it, and passes it
           on to invocations of commands.  Thus, MMMMAAAAKKKKEEEEFFFFLLLLAAAAGGGGSSSS always
           contains the current input options.  This proves very useful
           for ``super-makes''.  In fact, as noted above, when the ----nnnn
           option is used, the command $$$$((((MMMMAAAAKKKKEEEE)))) is executed anyway;
           hence, one can perform a mmmmaaaakkkkeeee ----nnnn recursively on a whole
           software system to see what would have been executed.  This
           is because the ----nnnn is put in MMMMAAAAKKKKEEEEFFFFLLLLAAAAGGGGSSSS and passed to further
           invocations of $$$$((((MMMMAAAAKKKKEEEE)))).  This is one way of debugging all of
           the makefiles for a software project without actually doing
           anything.

         MMMMaaaaccccrrrroooossss
           Entries of the form _s_t_r_i_n_g_1 ==== _s_t_r_i_n_g_2 are macro definitions.
           _S_t_r_i_n_g_2 is defined as all characters up to a comment
           character or an unescaped newline.  Subsequent appearances
           of $(_s_t_r_i_n_g_1[:_s_u_b_s_t_1=[_s_u_b_s_t_2]]) are replaced by _s_t_r_i_n_g_2.
           The parentheses are optional if a single character macro
           name is used and there is no substitute sequence.  The
           optional :_s_u_b_s_t_1=_s_u_b_s_t_2 is a substitute sequence.  If it is
           specified, all non-overlapping occurrences of _s_u_b_s_t_1 in the
           named macro are replaced by _s_u_b_s_t_2.  Strings (for the
           purposes of this type of substitution) are delimited by
           blanks, tabs, new-line characters, and beginnings of lines.
           An example of the use of the substitute sequence is shown
           under _L_i_b_r_a_r_i_e_s.

         IIIInnnntttteeeerrrrnnnnaaaallll MMMMaaaaccccrrrroooossss
           There are five internally maintained macros which are useful
           for writing rules for building targets.

           $$$$****   The macro $$$$**** stands for the file name part of the
                current dependent with the suffix deleted.  It is
                evaluated only for inference rules.

           $$$$@@@@   The $$$$@@@@ macro stands for the full target name of the
                current target.  It is evaluated only for explicitly
                named dependencies.

           $$$$<<<<   The $$$$<<<< macro is only evaluated for inference rules or
                the ....DDDDEEEEFFFFAAAAUUUULLLLTTTT rule.  It is the module which is out of
                date with respect to the target (i.e., the
                ``manufactured'' dependent file name).  Thus, in the
                ....cccc....oooo rule, the $$$$<<<< macro would evaluate to the ....cccc file.
                An example for making optimized ....oooo files from ....cccc files
                is:

                     .c.o:
                          cc -c -O $*.c




      Page 4                                                   (9010-E)






      MMMMAAAAKKKKEEEE((((1111))))                     ((((UUUUNNNNIIIIXXXX 5555....2222))))                    MMMMAAAAKKKKEEEE((((1111))))



                or:

                     .c.o:
                          cc -c -O $<

           $$$$????   The $$$$???? macro is evaluated when explicit rules from the
                makefile are evaluated.  It is the list of
                prerequisites that are out of date with respect to the
                target; essentially, those modules which must be
                rebuilt.

           $$$$%%%%   The $$$$%%%% macro is only evaluated when the target is an
                archive library member of the form lllliiiibbbb((((ffffiiiilllleeee....oooo)))).  In
                this case, $$$$@@@@ evaluates to lllliiiibbbb and $$$$%%%% evaluates to the
                library member, ffffiiiilllleeee....oooo.

           Four of the five macros can have alternative forms.  When an
           upper case DDDD or FFFF is appended to any of the four macros the
           meaning is changed to ``directory part'' for DDDD and ``file
           part'' for FFFF.  Thus, $$$$((((@@@@DDDD)))) refers to the directory part of
           the string $$$$@@@@.  If there is no directory part, ....//// is
           generated.  The only macro excluded from this alternative
           form is $$$$????.  The reasons for this are debatable.

         SSSSuuuuffffffffiiiixxxxeeeessss
           Certain names (for instance, those ending with ....oooo) have
           inferable prerequisites such as ....cccc, ....ssss, etc.  If no update
           commands for such a file appear in _m_a_k_e_f_i_l_e, and if an
           inferable prerequisite exists, that prerequisite is compiled
           to make the target.  In this case, _m_a_k_e has inference rules
           which allow building files from other files by examining the
           suffixes and determining an appropriate inference rule to
           use.  The current default inference rules are:

                .c .c~ .sh .sh~ .c.o .c~.o .c~.c .s.o .s~.o .y.o .y~.o
                .l.o .l~.o
                .y.c .y~.c .l.c .c.a .c~.a .s~.a .h~.h
                .f .f~ .f.o .f~.o .f~.f

           To print out the rules compiled into the _m_a_k_e on any
           machine, use the following:

                make -fp - 2>/dev/null </dev/null

           The only peculiarity in this output is the ((((nnnnuuuullllllll)))) string
           which _p_r_i_n_t_f(3S) prints when handed a null string.

           A tilde in the above rules refers to an SCCS file (see
           _s_c_c_s_f_i_l_e(4)).  Thus, the rule ....cccc~~~~....oooo would transform an SCCS
           C source file into an object file (....oooo).  Because the ssss.... of
           the SCCS files is a prefix it is incompatible with _m_a_k_e's
           suffix point-of-view.  Hence, the tilde is a way of changing



      Page 5                                                   (9010-E)






      MMMMAAAAKKKKEEEE((((1111))))                     ((((UUUUNNNNIIIIXXXX 5555....2222))))                    MMMMAAAAKKKKEEEE((((1111))))



           any file reference into an SCCS file reference.

           A rule with only one suffix (i.e. ....cccc::::) is the definition of
           how to build _x from _x....cccc.  In effect, the other suffix is
           null.  This is useful for building targets from only one
           source file (e.g., shell procedures, simple C programs).

           Additional suffixes are given as the dependency list for
           ....SSSSUUUUFFFFFFFFIIIIXXXXEEEESSSS.  Order is significant; the first possible name
           for which both a file and a rule exist is inferred as a
           prerequisite.  The default list is:

                ....SSSSUUUUFFFFFFFFIIIIXXXXEEEESSSS: .o .c .y .l .s

           Here again, the above command for printing the internal
           rules will display the list of suffixes implemented on the
           current machine.  Multiple suffix lists accumulate;
           ....SSSSUUUUFFFFFFFFIIIIXXXXEEEESSSS:::: with no dependencies clears the list of suffixes.

         IIIInnnnffffeeeerrrreeeennnncccceeee RRRRuuuulllleeeessss
           The first example can be done more briefly:

                pgm: a.o b.o
                     cc a.o b.o -o pgm
                a.o b.o: incl.h

           This is because _m_a_k_e has a set of internal rules for
           building files.  The user may add rules to this list by
           simply putting them in the _m_a_k_e_f_i_l_e.

           Certain macros are used by the default inference rules to
           permit the inclusion of optional matter in any resulting
           commands.  For example, CCCCFFFFLLLLAAAAGGGGSSSS, LLLLFFFFLLLLAAAAGGGGSSSS, and YYYYFFFFLLLLAAAAGGGGSSSS are used
           for compiler options to _c_c(1), _l_e_x(1), and _y_a_c_c(1)
           respectively.  Again, the previous method for examining the
           current rules is recommended.

           The inference of prerequisites can be controlled.  The rule
           to create a file with suffix ....oooo from a file with suffix ....cccc
           is specified as an entry with ....cccc....oooo:::: as the target and no
           dependents.  Shell commands associated with the target
           define the rule for making a ....oooo file from a ....cccc file.  Any
           target that has no slashes in it and starts with a dot is
           identified as a rule and not a true target.

         LLLLiiiibbbbrrrraaaarrrriiiieeeessss
           If a target or dependency name contains parenthesis, it is
           assumed to be an archive library, the string within
           parenthesis referring to a member within the library.  Thus
           lllliiiibbbb((((ffffiiiilllleeee....oooo)))) and $$$$((((LLLLIIIIBBBB))))((((ffffiiiilllleeee....oooo)))) both refer to an archive
           library which contains ffffiiiilllleeee....oooo. (This assumes the LLLLIIIIBBBB macro
           has been previously defined.)The expression $$$$((((LLLLIIIIBBBB))))((((ffffiiiilllleeee1111....oooo



      Page 6                                                   (9010-E)






      MMMMAAAAKKKKEEEE((((1111))))                     ((((UUUUNNNNIIIIXXXX 5555....2222))))                    MMMMAAAAKKKKEEEE((((1111))))



           ffffiiiilllleeee2222....oooo)))) is not legal.  Rules pertaining to archive
           libraries have the form ...._X_X....aaaa where the _X_X is the suffix
           from which the archive member is to be made.  An unfortunate
           byproduct of the current implementation requires the _X_X to
           be different from the suffix of the archive member.  Thus,
           one cannot have lllliiiibbbb((((ffffiiiilllleeee....oooo)))) depend upon ffffiiiilllleeee....oooo explicitly.
           The most common use of the archive interface follows.  Here,
           we assume the source files are all C type source:

                lib: lib(file1.o) lib(file2.o) lib(file3.o)
                     @echo lib is now up to date
                .c.a:
                     $(CC) -c $(CFLAGS) $<
                     ar rv $@ $*.o
                     rm -f $*.o

           In fact, the ....cccc....aaaa rule listed above is built into _m_a_k_e and
           is unnecessary in this example.  A more interesting, but
           more limited example of an archive library maintenance
           construction follows:

                lib: lib(file1.o) lib(file2.o) lib(file3.o)
                     $(CC) -c $(CFLAGS) $(?:.o=.c)
                     ar rv lib $?
                     rm $?  @echo lib is now up to date
                .c.a:;

           Here the substitution mode of the macro expansions is used.
           The $$$$????  list is defined to be the set of object file names
           (inside lllliiiibbbb) whose C source files are out of date.  The
           substitution mode translates the ....oooo to ....cccc.  (Unfortunately,
           one cannot as yet transform to ....cccc~~~~; however, this may become
           possible in the future.)Note also, the disabling of the
           ....cccc....aaaa:::: rule, which would have created each object file, one
           by one.  This particular construct speeds up archive library
           maintenance considerably.  This type of construct becomes
           very cumbersome if the archive library contains a mix of
           assembly programs and C programs.

      FFFFIIIILLLLEEEESSSS
           [Mm]akefile and s....[Mm]akefile

      SSSSEEEEEEEE AAAALLLLSSSSOOOO
           sh(1).
           _M_a_k_e-_A _P_r_o_g_r_a_m _f_o_r _M_a_i_n_t_a_i_n_i_n_g _C_o_m_p_u_t_e_r _P_r_o_g_r_a_m_s and _A_n
           _A_u_g_m_e_n_t_e_d _V_e_r_s_i_o_n _o_f _M_a_k_e in _A _P_r_o_g_r_a_m_m_e_r_s _G_u_i_d_e _t_o _R_O_S .

      BBBBUUUUGGGGSSSS
           Some commands return non-zero status inappropriately; use ----iiii
           to overcome the difficulty.  Commands that are directly
           executed by the shell, notably _c_d(1), are ineffectual across
           new-lines in _m_a_k_e.  The syntax lllliiiibbbb((((ffffiiiilllleeee1111....oooo ffffiiiilllleeee2222....oooo ffffiiiilllleeee3333....oooo))))



      Page 7                                                   (9010-E)






      MMMMAAAAKKKKEEEE((((1111))))                     ((((UUUUNNNNIIIIXXXX 5555....2222))))                    MMMMAAAAKKKKEEEE((((1111))))



           is illegal.  You cannot build lllliiiibbbb((((ffffiiiilllleeee....oooo)))) from ffffiiiilllleeee....oooo.  The
           macro $$$$((((aaaa::::....oooo====....cccc~~~~)))) doesn't work.





















































      Page 8                                                   (9010-E)



