dvadura@watdragon.waterloo.edu (Dennis Vadura) (07/27/90)
Posting-number: Volume 14, Issue 21
Submitted-by: dvadura@watdragon.waterloo.edu (Dennis Vadura)
Archive-name: dmake/part11
#!/bin/sh
# this is part 11 of a multipart archive
# do not concatenate these parts, unpack them in order with /bin/sh
# file man/dmake.p continued
#
CurArch=11
if test ! -r s2_seq_.tmp
then echo "Please unpack part 1 first!"
exit 1; fi
( read Scheck
if test "$Scheck" != $CurArch
then echo "Please unpack part $Scheck next!"
exit 1;
else exit 0; fi
) < s2_seq_.tmp || exit 1
echo "x - Continuing file man/dmake.p"
sed 's/^X//' << 'SHAR_EOF' >> man/dmake.p
X $$$$ expands to $, {{{{ expands to {, }}}} expands to }, and the
X strings <<++ and ++>> are reserved for use in recipe scripts for
X starting and terminating a text diversion respectively.
X
X The difference between $? and $^ can best be illustrated by
X an example, consider:
X
X fred.out : joe amy hello
X rules for making fred
X
X fred.out : my.c your.h his.h her.h # more prerequisites
X
X Assume joe, amy, and my.c are newer then fred.out. When
X ddmmaakkee executes the recipe for making fred.out the values of
X the following macros will be:
X
X $@ --> fred.out
X $* --> fred
X $? --> joe amy my.c # note the difference between $? and $^
X $^ --> joe amy
X $< --> joe amy hello
X $& --> joe amy hello my.c your.h his.h her.h
X
X
XDDYYNNAAMMIICC PPRREERREEQQUUIISSIITTEESS
X ddmmaakkee looks for prerequisites whose names contain macro
X expansions during target processing. Any such prerequisites
X are expanded and the result of the expansion is used as the
X prerequisite name. As an example the line:
X
X fred : $$@.c
X
X
X
XVersion 3.50 UW 25
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X causes the $$@ to be expanded when ddmmaakkee is making fred, and
X it resolves to the target _f_r_e_d. This enables dynamic prere-
X quisites to be generated. The value of @ may be modified by
X any of the valid macro modifiers. So you can say for exam-
X ple:
X
X fred.out : $$(@:b).c
X
X where the $$(@:b) expands to _f_r_e_d. Note the use of $$
X instead of $ to indicate the dynamic expansion, this is due
X to the fact that the rule line is expanded when it is ini-
X tially parsed, and $$ then returns $ which later triggers
X the dynamic prerequisite expansion. If you really want a $
X to be part of a prerequisite name you must use $$$$.
X Dynamic macro expansion is performed in all user defined
X rules, and the special targets .SOURCE*, and .INCLUDEDIRS.
X
XBBIINNDDIINNGG TTAARRGGEETTSS
X This operation takes a target name and binds it to an exist-
X ing file, if possible. ddmmaakkee makes a distinction between
X the internal target name of a target and it's associated
X external file name. Thus it is possible for a target's
X internal name and its external file name to differ. To per-
X form the binding, the following set of rules is used.
X Assume that we are trying to bind a target whose name is of
X the form _X_._s_u_f_f, where _._s_u_f_f is the suffix and _X is the stem
X portion (ie. that part which contains the directory and the
X basename). ddmmaakkee takes this target name and performs a
X series of search operations that try to find a suitably
X named file in the external file system. The search opera-
X tion is user controlled via the settings of the various
X .SOURCE targets.
X
X 1. If target has the .SYMBOL attribute set then look
X for it in the library. If found, replace the tar-
X get name with the library member name and continue
X with step 2. If the name is not found then
X return.
X
X 2. Extract the suffix portion (that following the
X `.') of the target name. If the suffix is not
X null, look up the special target .SOURCE.<suff>
X (<suff> is the suffix). If the special target
X exists then search each directory given in the
X .SOURCE.<suff> prerequisite list for the target.
X If the target's suffix was null (ie. _._s_u_f_f was
X empty) then perform the above search but use the
X special target .SOURCE.NULL instead. If at any
X point a match is found then terminate the search.
X If a directory in the prerequisite list is the
X special name `.NULL ' perform a stat for the full
X target name without prepending any directory
X
X
X
XVersion 3.50 UW 26
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X portion (ie. prepend the NULL directory). (a
X default target of '.SOURCE : .NULL' is defined by
X ddmmaakkee at startup, and is user redefinable)
X
X 3. The search in step 2. failed. Repeat the same
X search but this time use the special target
X .SOURCE.
X
X 4. The search in step 3. failed. If the target has
X the library member attribute (.LIBMEMBER) set then
X try to find the target in the library which was
X passed along with the .LIBMEMBER attribute (see
X the MAKING LIBRARIES section). The bound file
X name assigned to a target which is successfully
X located in a library is the same name that would
X be assigned had the search failed (see 5.).
X
X 5. The search failed. Either the target was not
X found in any of the search directories or no
X applicable .SOURCE special targets exist. If
X applicable .SOURCE special targets exist, but the
X target was not found, then ddmmaakkee assigns the first
X name searched as the bound file name. If no
X applicable .SOURCE special targets exist, then the
X full original target name becomes the bound file
X name.
X
X There is potential here for a lot of search operations. The
X trick is to define .SOURCE.x special targets with short
X search lists and leave .SOURCE as short as possible. The
X search algorithm has the following useful side effect. When
X a target having the .LIBMEMBER (library member) attribute is
X searched for, it is first searched for as an ordinary file.
X When a number of library members require updating it is
X desirable to compile all of them first and to update the
X library at the end in a single operation. If one of the
X members does not compile and ddmmaakkee stops, then the user may
X fix the error and make again. ddmmaakkee will not remake any of
X the targets whose object files have already been generated
X as long as none of their prerequisite files have been modi-
X fied as a result of the fix.
X
X When defining .SOURCE and .SOURCE.x targets the construct
X
X .SOURCE :
X .SOURCE : fred gery
X
X is equivalent to
X
X .SOURCE :- fred gery
X
X
X
X
X
XVersion 3.50 UW 27
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X ddmmaakkee correctly handles the UNIX Make variable VPATH. By
X definition VPATH contains a list of ':' separated direc-
X tories to search when looking for a target. ddmmaakkee maps
X VPATH to the following special rule:
X
X .SOURCE :^ $(VPATH:s/:/ /)
X
X Which takes the value of VPATH and sets .SOURCE to the same
X set of directories as specified in VPATH.
X
XPPEERRCCEENNTT((%%)) RRUULLEESS AANNDD MMAAKKIINNGG IINNFFEERREENNCCEESS
X When ddmmaakkee makes a target it's set of prerequisites (if any)
X must exist and the target must have a recipe which ddmmaakkee can
X use to make it. If the makefile does not specify an expli-
X cit recipe for the target then ddmmaakkee uses special rules to
X try to infer a recipe which it can use to make the target.
X Previous versions of Make perform this task by using rules
X that are defined by targets of the form .<suffix>.<suffix>
X and by using the .SUFFIXES list of suffixes. The exact
X workings of this mechanism were sometimes difficult to
X understand and often limiting in their usefulness. Instead,
X ddmmaakkee supports the concept of _%_-_m_e_t_a rules. The syntax and
X semantics of these rules differ from standard rule lines as
X follows:
X
X _<_%_-_t_a_r_g_e_t_> [_<_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_>]
X
X where _%_-_t_a_r_g_e_t is a target containing exactly a single `%'
X sign, _a_t_t_r_i_b_u_t_e_s is a list (possibly empty) of attributes,
X _r_u_l_e_o_p is the standard set of rule operators, _%_-_p_r_e_r_e_-
X _q_u_i_s_i_t_e_s , if present, is a list of prerequisites containing
X zero or more `%' signs, and _r_e_c_i_p_e_, if present, is the first
X line of the recipe.
X
X The _%_-_t_a_r_g_e_t defines a pattern against which a target whose
X recipe is being inferred gets matched. The pattern match
X goes as follows: all chars are matched exactly from left to
X right up to but not including the % sign in the pattern, %
X then matches the longest string from the actual target name
X not ending in the suffix given after the % sign in the pat-
X tern. Consider the following examples:
X
X %.c matches fred.c but not joe.c.Z
X dir/%.c matches dir/fred.c but not dd/fred.c
X fred/% matches fred/joe.c but not f/joe.c
X % matches anything
X
X In each case the part of the target name that matched the %
X sign is retained and is substituted for any % signs in the
X prerequisite list of the %-meta rule when the rule is
X selected during inference and ddmmaakkee constructs the depen-
X dency specified by the %-meta rule for the actual target.
X
X
X
XVersion 3.50 UW 28
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X As an example the following %-meta rules describe the fol-
X lowing:
X
X %.c : %.y ; recipe...
X
X describes how to make any file ending in .c if a correspond-
X ing file ending in .y can be found.
X
X foo%.o : fee%.k ; recipe...
X
X is used to describe how to make fooxxxx.o from feexxxx.k.
X
X %.a :; recipe...
X
X describes how to make a file whose suffix is .a without
X inferring any prerequisites.
X
X %.c : %.y yaccsrc/%.y ; recipe...
X
X is a short form for the construct:
X
X %.c : %.y ; recipe...
X %.c : yaccsrc/%.y ; recipe...
X
X ie. It is possible to specify the same recipe for two
X %-rules by giving more than one prerequisite in the prere-
X quisite list. A more interesting example is:
X
X % : RCS/%,v ; co $@
X
X which describes how to take any target and check it out of
X the RCS directory if the corresponding file exists in the
X RCS directory. The equivalent SCCS rule would be:
X
X % : s.% ; get $@
X
X
X The previous RCS example defines an infinite rule, because
X it says how to make _a_n_y_t_h_i_n_g from RCS/%,v, and _a_n_y_t_h_i_n_g also
X includes RCS/fred.c,v. To limit the size of the graph that
X results from such rules ddmmaakkee uses the macro variable PREP
X (stands for % repetition). By default the value of this
X variable is 0, which says that no repetitions of a %-rule
X are to be generated. If it is set to something greater than
X 0, then that many repetitions of any infinite %-rule are
X allowed. If in the above example PREP was set to 1, then
X ddmmaakkee would generate the dependency graph:
X
X % --> RCS/%,v --> RCS/RCS/%,v,v
X
X Where each link is assigned the same recipe as the first
X link. PREP should be used only in special cases, since it
X
X
X
XVersion 3.50 UW 29
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X may result in a large increase in the number of possible
X prerequisites tested.
X
X ddmmaakkee supports dynamic prerequisite generation for prere-
X quisites of %-meta rules. This is best illustrated by an
X example. The RCS rule shown above can infer how to check
X out a file from a corresponding RCS file only if the target
X is a simple file name with no directory information. That
X is, the above rule can infer how to find _R_C_S_/_f_r_e_d_._c_,_v from
X the target _f_r_e_d_._c, but cannot infer how to find
X _s_r_c_d_i_r_/_R_C_S_/_f_r_e_d_._c_,_v from _s_r_c_d_i_r_/_f_r_e_d_._c because the above
X rule will cause ddmmaakkee to look for RCS/srcdir/fred.c,v; which
X does not exist (assume that srcdir has it's own RCS direc-
X tory as is the common case).
X
X A more versatile formulation of the above RCS check out rule
X is the following:
X
X % : $$(@:d)RCS/$$(@:f),v : co $@
X
X This rule uses the dynamic macro $@ to specify the prere-
X quisite to try to infer. During inference of this rule the
X macro $@ is set to the value of the target of the %-meta
X rule and the appropriate prerequisite is generated by
X extracting the directory portion of the target name (if
X any), appending the string _R_C_S_/ to it, and appending the
X target file name with a trailing _,_v attached to the previous
X result.
X
X ddmmaakkee can also infer indirect prerequisites. An inferred
X target can have a list of prerequisites added that will not
X show up in the value of $< but will show up in the value of
X $? and $&. Indirect prerequisites are specified in an
X inference rule by quoting the prerequisite with single
X quotes. For example, if you had the explicit dependency:
X
X fred.o : fred.c ; rule to make fred.o
X fred.o : local.h
X
X then this can be infered for fred.o from the following
X inference rule:
X
X %.o : %.c 'local.h' ; rule to make a .o from a .c
X
X You may infer indirect prerequisites that are a function of
X the value of '%' in the current rule. The meta-rule:
X
X %.o : %.c '$(INC)/%.h' ; rule to make a .o from a .c
X
X infers an indirect prerequisite found in the INC directory
X whose name is the same as the expansion of $(INC), and the
X prerequisite name depends on the base name of the current
X
X
X
XVersion 3.50 UW 30
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X target. The set of indirect prerequisites is attached to
X the meta rule in which they are specified and are inferred
X only if the rule is used to infer a recipe for a target.
X They do not play an active role in driving the inference
X algorithm. The construct:
X
X %.o : %.c %.f 'local.h'; recipe
X
X is equivalent to:
X
X %.o : %.c 'local.h' : recipe
X %.o : %.f 'local.h' : recipe
X
X
X If any of the attributes .SETDIR, .EPILOG, .PROLOG, .SILENT,
X .PRECIOUS, .LIBRARY, and .IGNORE are given for a %-rule then
X when that rule is bound to a target as the result of an
X inference, the target's set of attributes is augmented by
X the attributes from the above set that are specified in the
X bound %-rule. Other attributes specified for %-meta rules
X are not inherited by the target. The .SETDIR attribute is
X treated in a special way. If the target already had a .SET-
X DIR attribute set and the bound %-rule also specified a
X .SETDIR attribute then the one originally specified with the
X target prevails. During inference any .SETDIR attributes
X for the inferred prerequisite are honored. The directories
X must exist for a %-meta rule to be selected as a possible
X inference path. If the directories do not exist no error
X message is issued, instead the corresponding path in the
X inference graph is simply rejected.
X
X ddmmaakkee also supports the old format special target
X .<suffix>.<suffix> by identifying any rules of this form and
X mapping them to the appropriate %-rule. So for example if
X an old makefile contains the construct:
X
X .c.o :; cc -c $< -o $@
X
X ddmmaakkee maps this into the following %-rule:
X
X %.o : %.c; cc -c $< -o $@
X
X Furthermore, ddmmaakkee understands several SYSV AUGMAKE special
X targets and maps them into corresponding %-meta rules.
X These transformation must be enabled by providing the -A
X flag on the command line or by setting the value of AUGMAKE
X to non NULL. The construct
X
X .suff :; recipe
X
X gets mapped into:
X
X
X
X
XVersion 3.50 UW 31
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X % : %.suff; recipe
X
X and the construct
X
X .c~.o :; recipe
X
X gets mapped into:
X
X %.o : s.%.c ; recipe
X
X In general, a special target of the form .<str>~ is replaced
X by the %-rule construct s.%.<str>, thereby providing support
X for the syntax used by SYSV AUGMAKE for providing SCCS sup-
X port. When enabled, these mappings allow to processing of
X existing SYSV makefiles without modifications.
X
X ddmmaakkee bases all of it's inferences on the inference graph
X constructed from the %-rules defined in the makefile. It
X knows exactly which targets can be made from which prere-
X quisites by making queries on the inference graph. For this
X reason .SUFFIXES is not needed and is completely ignored.
X
X For a %-meta rule to be inferred as the rule whose recipe
X will be used to make a target, the target's name must match
X the %-target pattern, and any inferred %-prerequisite must
X already exist or have an explicit recipe so that the prere-
X quisite can be made. Without _t_r_a_n_s_i_t_i_v_e _c_l_o_s_u_r_e on the
X inference graph the above rule describes precisely when an
X inference match terminates the search. If transitive clo-
X sure is enabled (the usual case), and a prerequisite does
X not exist or cannot be made, then ddmmaakkee invokes the infer-
X ence algorithm recursively on the prerequisite to see if
X there is some way the prerequisite can be manufactured. For
X if the prerequisite can be made then the current target can
X also be made using the current %-meta rule. This means that
X there is no longer a need to give a rule for making a .o
X from a .y if you have already given a rule for making a .o
X from a .c and a .c from a .y. In such cases ddmmaakkee can infer
X how to make the .o from the .y via the intermediary .c and
X will remove the .c when the .o is made. Transitive closure
X can be disabled by giving the -T switch on the command line.
X
X A word of caution. ddmmaakkee bases its transitive closure on
X the %-meta rule targets. When it performs transitive clo-
X sure it infers how to make a target from a prerequisite by
X performing a pattern match as if the potential prerequisite
X were a new target. The set of rules:
X
X %.o : %.c :; rule for making .o from .c
X %.c : %.y :; rule for making .c from .y
X % : RCS/%,v :; check out of RCS file
X
X
X
X
XVersion 3.50 UW 32
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X will, by performing transitive closure, allow ddmmaakkee to infer
X how to make a .o from a .y using a .c as an intermediate
X temporary file. Additionally it will be able to infer how
X to make a .y from an RCS file, as long as that RCS file is
X in the RCS directory and has a name which ends in .y,v. The
X transitivity computation is performed dynamically for each
X target that does not have a recipe. This has potential to
X be very slow if the %-meta rules are not carefully speci-
X fied. The .NOINFER attribute is used to mark a %-meta node
X as being a final target during inference. Any node with
X this attribute set will not be used for subsequent infer-
X ences. As an example the node RCS/%,v is marked as a final
X node since we know that if the RCS file does not exist there
X likely is no other way to make it. Thus the standard
X startup makefile contains the entry:
X .NOINFER : RCS/%,v
X Thereby indicating that the RCS file is the end of the
X inference chain.
X
X ddmmaakkee tries to remove intermediate files resulting from
X transitive closure if the file is not marked as being PRE-
X CIOUS, or the --uu flag was not given on the command line, and
X if the inferred intermediate did not previously exist.
X Intermediate targets that existed prior to being made are
X never removed. This is in keeping with the philosophy that
X ddmmaakkee should never remove things from the file system that
X it did not add. If the special target .REMOVE is defined
X and has a recipe then ddmmaakkee constructs a list of the inter-
X mediate files to be removed and makes them prerequisites of
X .REMOVE. It then makes .REMOVE thereby removing the prere-
X quisites if the recipe of .REMOVE says to. Typically
X .REMOVE is defined in the startup file as:
X
X ".REMOVE :; $(RM) $<".
X
XMMAAKKIINNGG TTAARRGGEETTSS
X In order to update a target ddmmaakkee must execute a recipe.
X When a recipe needs to be executed it is first expanded so
X that any macros in the recipe text are expanded, and it is
X then either executed directly or passed to a shell. ddmmaakkee
X supports two types of recipes. The regular recipes and
X group recipes.
X
X When a regular recipe is invoked ddmmaakkee executes each line of
X the recipe separately using a new copy of a shell if a shell
X is required. Thus effects of commands do not generally per-
X sist across recipe lines. (e.g. cd requests in a recipe
X line do not carry over to the next recipe line) The decision
X on whether a shell is required to execute a command is based
X on the value of the macro SHELLMETAS. If any character in
X the value of SHELLMETAS is found in the expanded recipe
X text-line then the command is executed using a shell,
X
X
X
XVersion 3.50 UW 33
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X otherwise the command is executed directly. The shell that
X is used for execution is given by the value of the macro
X SHELL. The flags that are passed to the shell are given by
X the value of SHELLFLAGS. Thus ddmmaakkee constructs the command
X line:
X
X $(SHELL) $(SHELLFLAGS) $(expanded_recipe_command)
X
X Normally ddmmaakkee writes the command line that it is about to
X invoke to standard output. If the .SILENT attribute is set
X for the target or for the recipe line (via @), then the
X recipe line is not echoed.
X
X Group recipe processing is similar to that of regular
X recipes, except that a shell is always invoked. The shell
X that is invoked is given by the value of the macro GROUP-
X SHELL, and its flags are taken from the value of the macro
X GROUPFLAGS. If a target has the .PROLOG attribute set then
X ddmmaakkee prepends to the shell script the recipe associated
X with the special target .GROUPPROLOG, and if the attribute
X .EPILOG is set as well, then the recipe associated with the
X special target .GROUPEPILOG is appended to the script file.
X This facility can be used to always prepend a common header
X and common trailer to group recipes. Group recipes are
X echoed to standard output just like standard recipes, but
X are enclosed by lines beginning with [ and ].
X
XMMAAKKIINNGG LLIIBBRRAARRIIEESS
X Libraries are easy to maintain using ddmmaakkee. A library is a
X file containing a collection of object files. Thus to make
X a library you simply specify it as a target with the
X .LIBRARY attribute set and specify its list of prere-
X quisites. The prerequisites should be the object members
X that are to go into the library. When ddmmaakkee makes the
X library target it uses the .LIBRARY attribute to pass to the
X prerequisites the .LIBMEMBER attribute and the name of the
X library. This enables the file binding mechanism to look
X for the member in the library if an appropriate object file
X cannot be found. A small example best illustrates this.
X
X mylib.a .LIBRARY : mem1.o mem2.o mem3.o
X rules for making library...
X # remember to remove .o's when lib is made
X
X # equivalent to: '%.o : %.c ; ...'
X .c.o :; rules for making .o from .c say
X
X ddmmaakkee will use the .c.o rule for making the library members
X if appropriate .c files can be found using the search rules.
X NOTE: this is not specific in any way to C programs, they
X are simply used as an example.
X
X
X
X
XVersion 3.50 UW 34
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X ddmmaakkee tries to handle the old library construct format in a
X sensible way. The construct _l_i_b_(_m_e_m_b_e_r_._o_) is separated and
X the _l_i_b portion is declared as a library target. The new
X target is defined with the .LIBRARY attribute set and the
X _m_e_m_b_e_r_._o portion of the construct is declared as a prere-
X quisite of the lib target. If the construct _l_i_b_(_m_e_m_b_e_r_._o_)
X appears as a prerequisite of a target in the makefile, that
X target has the new name of the lib assigned as it's prere-
X quisite. Thus the following example:
X
X a.out : ml.a(a.o) ml.a(b.o); $(CC) -o $@ $<
X
X .c.o :; $(CC) -c $(CFLAGS) -o $@ $<
X %.a:
X ar rv $@ $<
X ranlib $@
X rm -rf $<
X
X constructs the following dependency graph.
X
X a.out : ml.a; $(CC) -o $@ $<
X ml.a .LIBRARY : a.o b.o
X
X %.o : %.c ; $(CC) -c $(CFLAGS) -o $@ $<
X %.a :
X ar rv $@ $<
X ranlib $@
X rm -rf $<
X
X and making a.out then works as expected.
X
X The same thing happens for any target of the form
X _l_i_b_(_(_e_n_t_r_y_)_). These targets have an additional feature in
X that the _e_n_t_r_y target has the .SYMBOL attribute set automat-
X ically.
X
X NOTE: If the notion of entry points is supported by the
X archive and by ddmmaakkee (currently not the case) then ddmmaakkee
X will search the archive for the entry point and return not
X only the modification time of the member which defines the
X entry but also the name of the member file. This name will
X then replace _e_n_t_r_y and will be used for making the member
X file. Once bound to an archive member the .SYMBOL attribute
X is removed from the target. This feature is presently dis-
X abled as there is little standardization among archive for-
X mats, and we have yet to find a makefile utilizing this
X feature (possibly due to the fact that it is unimplemented
X in most versions of UNIX Make).
X
XMMUULLTTII PPRROOCCEESSSSIINNGG
X If the architecture supports it then ddmmaakkee is capable of
X making a target's prerequisites in parallel. ddmmaakkee will
X
X
X
XVersion 3.50 UW 35
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X make as much in parallel as it can and use a number of child
X processes up to the maximum specified by MAXPROCESS or by
X the value supplied to the -P command line flag. A parallel
X make is enabled by setting the value of MAXPROCESS (either
X directly or via -P option) to a value which is > 1. ddmmaakkee
X guarantees that all dependencies as specified in the
X makefile are honored. A target will not be made until all
X of its prerequisites have been made. If a parallel make is
X being performed then the following restrictions on parallel-
X ism are enforced.
X
X 1. Individual recipe lines in a non-group recipe are
X performed sequentially in the order in which they
X are specified within the makefile and in parallel
X with the recipes of other targets.
X
X 2. If a target contains multiple recipe definitions
X (cf. :: rules) then these are performed sequen-
X tially in the order in which the :: rules are
X specified within the makefile and in parallel with
X the recipes of other targets.
X
X 3. If a target rule contains the `!' modifier, then
X the recipe is performed sequentially for the list
X of outdated prerequisites and in parallel with the
X recipes of other targets.
X
X 4. If a target has the .SEQUENTIAL attribute set then
X all of its prerequisites are made sequentially
X relative to one another (as if MAXPROCESS=1), but
X in parallel with other targets in the makefile.
X
X Note: If you specify a parallel make then the order of tar-
X get update and the order in which the associated recipes are
X invoked will not correspond to that displayed by the -n
X flag.
X
XCCOONNDDIITTIIOONNAALLSS
X ddmmaakkee supports a makefile construct called a _c_o_n_d_i_t_i_o_n_a_l.
X It allows the user to conditionally select portions of
X makefile text for input processing and to discard other por-
X tions. This becomes useful for writing makefiles that are
X intended to function for more than one target host and
X environment. The conditional expression is specified as
X follows:
X
X .IF _e_x_p_r_e_s_s_i_o_n
X ... if text ...
X .ELSE
X ... else text ...
X .END
X
X
X
X
XVersion 3.50 UW 36
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X The .ELSE portion is optional, and the conditionals may be
X nested (ie. the text may contain another conditional).
X .IF, .ELSE, and .END may appear anywhere in the makefile,
X but a single conditional expression may not span multiple
X makefiles.
X
X _e_x_p_r_e_s_s_i_o_n can be one of the following three forms:
X
X <text> | <text> == <text> | <text> != <text>
X
X where _t_e_x_t is either text or a macro expression. In any
X case, before the comparison is made, the expression is
X expanded. The text portions are then selected and compared.
X White space at the start and end of the text portion is dis-
X carded before the comparison. This means that a macro that
X evaluates to nothing but white space is considered a NULL
X value for the purpose of the comparison. In the first case
X the expression evaluates TRUE if the text is not NULL other-
X wise it evaluates FALSE. The remaining two cases both
X evaluate the expression on the basis of a string comparison.
X If a macro expression needs to be equated to a NULL string
X then compare it to the value of the macro $(NULL).
X
XEEXXAAMMPPLLEESS
X # A simple example showing how to use make
X #
X prgm : a.o b.o
X cc a.o b.o -o prgm
X a.o : a.c g.h
X cc a.c -o $@
X b.o : b.c g.h
X cc b.c -o $@
X
X In the previous example prgm is remade only if a.o and/or
X b.o is out of date with respect to prgm. These dependencies
X can be stated more concisely by using the inference rules
X defined in the standard startup file. The default rule for
X making .o's from .c's looks something like this:
X
X %.o : %.c; cc -c $(CFLAGS) -o $@ $<
X
X Since there exists a rule (defined in the startup file) for
X making .o's from .c's ddmmaakkee will use that rule for manufac-
X turing a .o from a .c and we can specify our dependencies
X more concisely.
X
X prgm : a.o b.o
X cc -o prgm $<
X a.o b.o : g.h
X
X A more general way to say the above using the new macro
X expansions would be:
X
X
X
XVersion 3.50 UW 37
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X SRC = a b
X OBJ = {$(SRC)}.o
X
X prgm : $(OBJ)
X cc -o $@ $<
X
X $(OBJ) : g.h
X
X If we want to keep the objects in a separate directory,
X called objdir, then we would write something like this.
X
X SRC = a b
X OBJ = {$(SRC)}.o
X
X prgm : $(OBJ)
X cc $< -o $@
X
X $(OBJ) : g.h
X %.o : %.c
X $(CC) -c $(CFLAGS) -o $(@:f) $<
X mv $(@:f) objdir
X
X .SOURCE.o : objdir # tell make to look here for .o's
X
X An example of building library members would go something
X like this: (NOTE: The same rules as above will be used to
X produce .o's from .c's)
X
X SRC = a b
X LIB = lib
X LIBm = { $(SRC) }.o
X
X prgm: $(LIB)
X cc -o $@ $(LIB)
X
X $(LIB) .LIBRARY : $(LIBm)
X ar rv $@ $<
X rm $<
X
X Finally, suppose that each of the source files in the previ-
X ous example had the `:' character in their target name.
X Then we would write the above example as:
X
X SRC = f:a f:b
X LIB = lib
X LIBm = "{ $(SRC) }.o" # put quotes around each token
X
X prgm: $(LIB)
X cc -o $@ $(LIB)
X
X $(LIB) .LIBRARY : $(LIBm)
X ar rv $@ $<
X
X
X
XVersion 3.50 UW 38
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X rm $<
X
XCCOOMMPPAATTIIBBIILLIITTYY
X There are two notable differences between ddmmaakkee and the
X standard version of BSD UNIX 4.2/4.3 Make.
X
X 1. BSD UNIX 4.2/4.3 Make supports wild card filename
X expansion for prerequisite names. Thus if a direc-
X tory contains a.h, b.h and c.h, then a line like
X
X target: *.h
X
X will cause UNIX make to expand the *.h into "a.h b.h
X c.h". ddmmaakkee does not support this type of filename
X expansion.
X
X 2. Unlike UNIX make, touching a library member causes
X ddmmaakkee to search the library for the member name and
X to update the library time stamp. This is only
X implemented in the UNIX version. MSDOS and other
X versions may not have librarians that keep file time
X stamps, as a result ddmmaakkee touches the library file
X itself, and prints a warning.
X
X ddmmaakkee is not compatible with GNU Make. In particular it
X does not understand GNU Make's macro expansions that query
X the file system.
X
X ddmmaakkee is fully compatible with SYSV AUGMAKE, and supports
X the following AUGMAKE features:
X
X 1. The word iinncclluuddee appearing at the start of a line
X can be used instead of the ".INCLUDE :" construct
X understood by ddmmaakkee.
X
X 2. The macro modifier expression $(macro:str=sub) is
X understood and is equivalent to the expression
X $(macro:s/str/sub), with the restriction that str
X must match the following regular expression:
X
X str[ |\t][ |\t]*
X
X (ie. str only matches at the end of a token where
X str is a suffix and is terminated by a space, a tab,
X or end of line)
X
X 3. The macro % is defined to be $@ (ie. $% expands to
X the same value as $@).
X
X 4. The AUGMAKE notion of libraries is handled
X correctly.
X
X
X
X
XVersion 3.50 UW 39
X
X
X
X
XDMAKE(p) Unsupported Software DMAKE(p)
X
X
X
X 5. When defining special targets for the inference
X rules and the AUGMAKE special target mapping is
X enabled then the special target .X is equivalent to
X the %-rule "% : %.X".
X
XLLIIMMIITTSS
X In some environments the length of an argument string is
X restricted. (e.g. MSDOS command line arguments cannot be
X longer than 128 bytes if you are using the standard
X command.com command interpreter as your shell, ddmmaakkee text
X diversions may help in these situations.)
X
XPPOORRTTAABBIILLIITTYY
X To write makefiles that can be moved from one environment to
X another requires some forethought. In particular you must
X define as macros all those things that may be different in
X the new environment. ddmmaakkee has two facilities that help to
X support writing portable makefiles, recursive macros and
X conditional expressions. The recursive macros, allow one to
X define environment configurations that allow different
X environments for similar types of operating systems. For
X example the same make script can be used for SYSV and BSD
X but with different macro definitions.
X
X To write a makefile that is portable between UNIX and MSDOS
X requires both features since in almost all cases you will
X need to define new recipes for making targets. The recipes
X will probably be quite different since the capabilities of
X the tools on each machine are different. Different macros
SHAR_EOF
echo "End of part 11"
echo "File man/dmake.p is continued in part 12"
echo "12" > s2_seq_.tmp
exit 0