dmake.man

在ATmega16芯片上移植的ucosii系统

     where _m_o_d_i_f_i_e_r___l_i_s_t is chosen from the set { B or b, D or d,
     E or e, F or f, I or i, L or l, S or s, T or t, U or u, ^, +
     } and

          b  - file (not including suffix) portion of path names
          d  - directory portion of all path names
          e  - suffix portion of path names
          f  - file (including suffix) portion of path names
          i  - inferred names of targets
          l  - macro value in lower case
          s  - simple pattern substitution
          t  - tokenization.
          u  - macro value in upper case
          ^  - prepend a prefix to each token
          +  - append a suffix to each token

     Thus if we have the example:

          test = d1/d2/d3/a.out f.out d1/k.out

     The following macro expansions produce the values on the
     right of '->' after expansion.

          $(test:d)             -> d1/d2/d3/ d1/
          $(test:b)             -> a f k
          $(test:f)             -> a.out f.out k.out
          ${test:db}            -> d1/d2/d3/a f d1/k
          ${test:s/out/in/:f}   -> a.in f.in k.in
          $(test:f:t"+")        -> a.out+f.out+k.out
          $(test:e)             -> .out .out .out
          $(test:u)             -> D1/D2/D3/A.OUT F.OUT D1/K.OUT

     If a token ends in a string composed from the value of the
     macro DIRBRKSTR (ie. ends in a directory separator string,
     e.g. '/' in UNIX) and you use the ::dd modifier then the
     expansion returns the directory name less the final direc-
     tory separator string.  Thus successive pairs of :d modif-
     iers each remove a level of directory in the token string.

     The tokenization modifier takes all white space separated
     tokens from the macro value and separates them by the quoted
     separator string.  The separator string may contain the fol-
     lowing escape codes \a => <bel>, \b => <backspace>, \f =>
     <formfeed>, \n => <nl>, \r => <cr>, \t => <tab>, \v =>



Version 3.9 PL0                 UW                             16
DMAKE(p)             Unsupported Free Software            DMAKE(p)



     <vertical tab>, \" => ", and \xxx => <xxx> where xxx is the
     octal representation of a character.  Thus the expansion:

          $(test:f:t"+\n")
     produces:
          a.out+
          f.out+
          k.out

     The prefix operator ^^ takes all white space separated tokens
     from the macro value and prepends _s_t_r_i_n_g to each.

          $(test:f:^mydir/)
     produces:
          mydir/a.out mydir/f.out mydir/k.out

     The suffix operator ++ takes all white space separated tokens
     from the macro value and appends _s_t_r_i_n_g to each.

          $(test:b:+.c)
     produces:
          a.c f.c k.c

     The next non-standard form of macro expansion allows for
     recursive macros.  It is possible to specify a $(_m_a_c_r_o___n_a_m_e)
     or ${_m_a_c_r_o___n_a_m_e} expansion where _m_a_c_r_o___n_a_m_e contains more $(
     ... ) or ${ ... } macro expansions itself.

     For example $(CC$(_HOST)$(_COMPILER)) will first expand
     CC$(_HOST)$(_COMPILER) to get a result and use that result
     as the name of the macro to expand.  This is useful for
     writing a makefile for more than one target environment.  As
     an example consider the following hypothetical case. Suppose
     that _HOST and _COMPILER are imported from the environment
     and are set to represent the host machine type and the host
     compiler respectively.

          CFLAGS_VAX_CC = -c -O     # _HOST == "_VAX", _COMPILER == "_CC"
          CFLAGS_PC_MSC = -c -ML # _HOST == "_PC",  _COMPILER == "_MSC"

          # redefine CFLAGS macro as:

          CFLAGS := $(CFLAGS$(_HOST)$(_COMPILER))

     This causes CFLAGS to take on a value that corresponds to
     the environment in which the make is being invoked.

     The final non-standard macro expansion is of the form:

          string1{token_list}string2





Version 3.9 PL0                 UW                             17
DMAKE(p)             Unsupported Free Software            DMAKE(p)



     where string1, string2 and token_list are expanded.  After
     expansion, string1 is prepended to each token found in
     token_list and string2 is appended to each resulting token
     from the previous prepend.  string1 and string2 are not del-
     imited by white space whereas the tokens in token_list are.
     A null token in the token list is specified using "".  Thus
     using another example we have:

          test/{f1 f2}.o     --> test/f1.o test/f2.o
          test/ {f1 f2}.o    --> test/ f1.o f2.o
          test/{f1 f2} .o    --> test/f1 test/f2 .o
          test/{"f1"  ""}.o  --> test/f1.o test/.o

          and

          test/{d1 d2}/{f1 f2}.o --> test/d1/f1.o test/d1/f2.o
                                     test/d2/f1.o test/d2/f2.o

     This last expansion is activated only when the first charac-
     ters of _t_o_k_e_n___l_i_s_t appear immediately after the opening '{'
     with no intervening white space.  The reason for this res-
     triction is the following incompatibility with Bourne Shell
     recipes.  The line

          { echo hello;}

     is valid /bin/sh syntax; while

          {echo hello;}

     is not.  Hence the latter triggers the enhanced macro expan-
     sion while the former causes it to be suppressed.  See the
     SPECIAL MACROS section for a description of the special mac-
     ros that ddmmaakkee defines and understands.

RRUULLEESS AANNDD TTAARRGGEETTSS
     A makefile contains a series of entries that specify depen-
     dencies.  Such entries are called _t_a_r_g_e_t_/_p_r_e_r_e_q_u_i_s_i_t_e or
     _r_u_l_e definitions.  Each rule definition is optionally fol-
     lowed by a set of lines that provide a recipe for updating
     any targets defined by the rule.  Whenever ddmmaakkee attempts to
     bring a target up to date and an explicit recipe is provided
     with a rule defining the target, that recipe is used to
     update the target.  A rule definition begins with a line
     having the following syntax:

          _<_t_a_r_g_e_t_s_> [_<_a_t_t_r_i_b_u_t_e_s_>] _<_r_u_l_e_o_p_> [_<_p_r_e_r_e_q_u_i_s_i_t_e_s_>] [;_<_r_e_c_i_p_e_>]

     _t_a_r_g_e_t_s is a non-empty list of targets.  If the target is a
     special target (see SPECIAL TARGETS section below) then it
     must appear alone on the rule line.  For example:




Version 3.9 PL0                 UW                             18
DMAKE(p)             Unsupported Free Software            DMAKE(p)



          .IMPORT .ERROR : ...

     is not allowed since both .IMPORT and .ERROR are special
     targets.  Special targets are not used in the construction
     of the dependency graph and will not be made.

     _a_t_t_r_i_b_u_t_e_s is a possibly empty list of attributes.  Any
     attribute defined in the ATTRIBUTES section above may be
     specified.  All attributes will be applied to the list of
     named targets in the rule definition.  No other targets will
     be affected.


     NOTE:   As stated earlier, if both the target list and
             prerequisite list are empty but the attributes list
             is not, then the specified attributes affect all
             targets in the makefile.


     _r_u_l_e_o_p is a separator which is used to identify the targets
     from the prerequisites.  Optionally it also provides a
     facility for modifying the way in which ddmmaakkee handles the
     making of the associated targets.  In its simplest form the
     operator is a single ':', and need not be separated by white
     space from its neighboring tokens.  It may additionally be
     followed by any of the modifiers { !, ^, -, :, | }, where:


     !!    says execute the recipe for the associated targets once
          for each out of date prerequisite.  Ordinarily the
          recipe is executed once for all out of date prere-
          quisites at the same time.

     ^^    says to insert the specified prerequisites, if any,
          before any other prerequisites already associated with
          the specified targets.  In general, it is not useful to
          specify ^ with an empty list of prerequisites.

     --    says to clear the previous list of prerequisites before
          adding the new prerequisites.  Thus,

               .SUFFIXES :
               .SUFFIXES : .a .b

          can be replaced by

               .SUFFIXES :- .a .b

          however the old form still works as expected.  NOTE:
          .SUFFIXES is ignored by ddmmaakkee it is used here simply as
          an example.




Version 3.9 PL0                 UW                             19
DMAKE(p)             Unsupported Free Software            DMAKE(p)



     ::    When the rule operator is not modified by a second ':'
          only one set of rules may be specified for making a
          target.  Multiple definitions may be used to add to the
          list of prerequisites that a target depends on.  How-
          ever, if a target is multiply defined only one defini-
          tion may specify a recipe for making the target.

          When a target's rule operator is modified by a second
          ':' (:: for example) then this definition may not be
          the only definition with a recipe for the target.
          There may be other :: target definition lines that
          specify a different set of prerequisites with a dif-
          ferent recipe for updating the target. Any such target
          is made if any of the definitions find it to be out of
          date with respect to the related prerequisites and the
          corresponding recipe is used to update the target.  By
          definition all '::' recipes that are found to be out of
          date for are executed.

          In the following simple example, each rule has a `::'
          _r_u_l_e_o_p.  In such an operator we call the first `:' the
          operator, and the second `:' the modifier.

          a.o :: a.c b.h
             first recipe for making a.o

          a.o :: a.y b.h
             second recipe for making a.o

          If a.o is found to be out of date with respect to a.c
          then the first recipe is used to make a.o.  If it is
          found out of date with respect to a.y then the second
          recipe is used.  If a.o is out of date with respect to
          b.h then both recipes are invoked to make a.o.  In the
          last case the order of invocation corresponds to the
          order in which the rule definitions appear in the
          makefile.

     ||    Is defined only for PERCENT rule target definitions.
          When specified it indicates that the following con-
          struct should be parsed using the old semantinc mean-
          ing:

          %.o :| %.c %.r %.f ; some rule

          is equivalent to:

          %.o : %.c ; some rule
          %.o : %.r ; some rule
          %.o : %.f ; some rule





Version 3.9 PL0                 UW                             20
DMAKE(p)             Unsupported Free Software            DMAKE(p)



     Targets defined using a single `:' operator with a recipe
     may be redefined again with a new recipe by using a `:'
     operator with a `:' modifier.  This is equivalent to a tar-
     get having been initially defined with a rule using a `:'
     modifier.  Once a target is defined using a `:' modifier it
     may not be defined again with a recipe using only the `:'
     operator with no `:' modifier.  In both cases the use of a
     `:' modifier creates a new list of prerequisites and makes
     it the current prerequisite list for the target.  The `:'
     operator with no recipe always modifies the current list of
     prerequisites.  Thus assuming each of the following defini-
     tions has a recipe attached, then: