dvadura@watdragon.waterloo.edu (Dennis Vadura) (10/15/90)
Posting-number: Volume 15, Issue 67 Submitted-by: Dennis Vadura <dvadura@watdragon.waterloo.edu> Archive-name: dmake-3.6/part15 #!/bin/sh # this is part 15 of a multipart archive # do not concatenate these parts, unpack them in order with /bin/sh # file man/dmake.p continued # CurArch=15 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 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 X X XVersion 3.50 UW 30 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X X .SOURCE : X .SOURCE : fred gery X X is equivalent to X X .SOURCE :- fred gery 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 X X XVersion 3.50 UW 31 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X 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 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 X X XVersion 3.50 UW 32 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X 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 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 X X XVersion 3.50 UW 33 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X 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 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 .USESHELL, .SWAP, .PRECIOUS, .LIBRARY, and .IGNORE are given X for a %-rule then when that rule is bound to a target as the X result of an inference, the target's set of attributes is X augmented by the attributes from the above set that are X specified in the bound %-rule. Other attributes specified X for %-meta rules are not inherited by the target. The .SET- X DIR attribute is treated in a special way. If the target X already had a .SETDIR attribute set and the bound %-rule X also specified a .SETDIR attribute then the one originally X specified with the target prevails. During inference any X .SETDIR attributes for the inferred prerequisite are X honored. The directories must exist for a %-meta rule to be X selected as a possible inference path. If the directories X do not exist no error message is issued, instead the X corresponding path in the inference graph is simply X 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 X X XVersion 3.50 UW 34 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X 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 % : %.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 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 X X X XVersion 3.50 UW 35 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X X closure it infers how to make a target from a prerequisite X by performing a pattern match as if the potential prere- X quisite 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 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 X X X XVersion 3.50 UW 36 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X 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 or on the specification X of '+' or .USESHELL for the current recipe or target respec- X tively. If any character in the value of SHELLMETAS is X found in the expanded recipe text-line or the use of a shell X is requested explicitly via '+' or .USESHELL then the com- X mand is executed using a shell, otherwise the command is X executed directly. The shell that is used for execution is X given by the value of the macro SHELL. The flags that are X passed to the shell are given by the value of SHELLFLAGS. X Thus ddmmaakkee constructs the command 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 X X XVersion 3.50 UW 37 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X 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 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 X X XVersion 3.50 UW 38 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X 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 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 X X X XVersion 3.50 UW 39 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X X portions. This becomes useful for writing makefiles that X are 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 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 X X XVersion 3.50 UW 40 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X 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 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 X X X XVersion 3.50 UW 41 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X X previous 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 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 X X XVersion 3.50 UW 42 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X 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 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 X will be needed to help handle the smaller differences in the X two environments. X X NOTE: Unlike UNIX, MSDOS ddooeess maintain cd requests cross X single recipe lines. This is not portable, and your X makefiles will not work the same way if you depend on it. X Use the .IF ... .ELSE ... .END conditionals to supply dif- X ferent make scripts as necessary. X X X X X X XVersion 3.50 UW 43 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X XFFIILLEESS X Makefile, makefile, startup.mk (use dmake -V to tell you X where the startup file is) X XSSEEEE AALLSSOO X sh(1), csh(1), touch(1), f77(1), pc(1), cc(1) X S.I. Feldman _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_- X _g_r_a_m_s X XAAUUTTHHOORR X Dennis Vadura, CS Dept. University of Waterloo. X dvadura@watdragon.uwaterloo.ca X Many thanks to Carl Seger for his helpful suggestions, and X to Trevor John Thompson for his many excellent ideas and X informative bug reports. X XBBUUGGSS X Some system commands return non-zero status inappropriately. X Use --ii (`-' within the makefile) to overcome the difficulty. X X Some systems do not have easily accessible time stamps for X library members (MSDOS, AMIGA, etc) for these ddmmaakkee uses the X time stamp of the library instead and prints a warning the X first time it does so. This is almost always ok, except X when multiple makefiles update a single library file. In X these instances it is possible to miss an update if one is X not careful. X X X X X X X X X X X X X X X X X X X X X X X X X X X X XVersion 3.50 UW 44 SHAR_EOF echo "File man/dmake.p is complete" chmod 0640 man/dmake.p || echo "restore of man/dmake.p fails" echo "x - extracting man/dmake.nc (Text)" sed 's/^X//' << 'SHAR_EOF' > man/dmake.nc && X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X XNAME X dmake - maintain program groups, or interdependent files X XSYNOPSIS X dmake [-AeEhiknpqersStTuvVx] [-P#] [macro[*][+][:]=value] X [-f file] [target ...] X XDESCRIPTION X dmake executes commands found in an external file called a X makefile to update one or more target names. Each target X may depend on zero or more prerequisite targets. If any of X the target's prerequisites is newer than the target or if X the target itself does not exist, then dmake will attempt to X make the target. X X If no -f command line option is present then dmake searches X for an existing makefile from the list of prerequisites X specified for the special target .MAKEFILES (see the STARTUP X section for more details). If "-" is the name of the file X specified to the -f flag then dmake uses standard input as X the source of the makefile text. X X Any macro definitions (arguments with embedded "=" signs) X that appear on the command line are processed first and X supercede definitions for macros of the same name found X within the makefile. In general it is impossible for defin- X itions found inside the makefile to redefine a macro defined X on the command line, see the MACROS section for an excep- X tion. X X If no target names are specified on the command line, then X dmake uses the first non-special target found in the X makefile as the default target. See the SPECIAL TARGETS X section for the list of special targets and their function. X dmake is a re-implementation of the UNIX Make utility with X significant enhancements. Makefiles written for most previ- X ous versions of make will be handled correctly by dmake. X Known differences between dmake and other versions of make X are discussed in the COMPATIBILITY section found at the end X of this document. X XOPTIONS X -A Enable AUGMAKE special inference rule transformations X (see the "PERCENT(%) RULES" section), these are set to X off by default. X X -e Read the environment and define all strings of the form X 'ENV-VAR=evalue' defined within as macros whose name is X ENV-VAR, and whose value is 'evalue'. The environment X is processed prior to processing the user specified X makefile thereby allowing definitions in the makefile X to override definitions in the environment. X X X XVersion 3.50 UW 1 X X X X XDMAKE(p) Unsupported Software DMAKE(p) X X X X -E Same as -e, except that the environment is processed X after the user specified makefile has been processed X (thus definitions in the environment override defini- X tions in the makefile). The -e and -E options are X mutually exclusive. If both are given the latter one X takes effect. X X -f file X Use file as the source for the makefile text. Only one X -f option is allowed. X X -h Print the command summary for dmake. X X -i Tells dmake to ignore errors, and continue making other X targets. This is equivalent to the .IGNORE attribute X or macro. X X -k Causes dmake to ignore errors caused by command execu- X tion and to make all targets not depending on targets X that could not be made. Ordinarily dmake stops after a X command returns a non-zero status, specifying -k causes X dmake to ignore the error and continue to make as much X as possible. X X -n Causes dmake to print out what it would have executed, X but does not actually execute the commands. A special X check is made for the string "$(MAKE)" inside a recipe X line, if found, the line is expanded and invoked, X thereby enabling recursive makes to give a full X description of all that they will do. The check for X "$(MAKE)" is disabled inside group recipes. X X -p Print out a version of the digested makefile in human X readable form. (useful for debugging, but cannot be SHAR_EOF echo "End of part 15" echo "File man/dmake.nc is continued in part 16" echo "16" > s2_seq_.tmp exit 0