' Guide to MadGoat Make Utility December, 1998? This manual describes the MadGoat Make Utility (MMK),+ a "make" utility for VMS systems.A Revision/Update Information: This is a revised manual.> Operating System and Version: VAX/VMS V5.2 or later;= OpenVMS Alpha V1.5 or- later0 Software Version: MMK V3.8 Matthew Madison MadGoat Software  " ________________________ 28 December 1998= Permission is granted to copy and redistribute this* document for no commercial gain.? The information in this document is subject to change9 without notice and should not be construed as a9 commitment by the author. The author assumes no? responsibility for any errors that may appear in this document.= DISCLAIMER: The author and MadGoat Software make no; representations or warranties with respect to the? contents hereof and specifically disclaim any implied: warranties of merchantability or fitness for any particular purpose.; The following are trademarks of Digital Equipment Corporation:8 AXP DEC OpenVMS VAX VMS5 UNIX is a registered trademark of USL, Inc. __________? Copyright ©1993, 1994, 1995, 1996, 1997, 1998 MadGoat( Software. All Rights Reserved.  A _______________________________________________________ ContentsA _________________________________________________A PREFACE viiA _______________________________________________________A CHAPTER 1 INTRODUCTION 1-1A _________________________________________________A 1.1 OVERVIEW 1-1A _________________________________________________A 1.2 INVOKING MMK 1-2A _______________________________________________________A CHAPTER 2 DESCRIPTION FILES 2-1A _________________________________________________A 2.1 DESCRIPTION FILE COMPONENTS 2-1A _________________________________________________A 2.2 USING INFERENCE RULES 2-2A _________________________________________________A 2.3 DEFINING INFERENCE RULES 2-3A _________________________________________________6 2.4 FORCED SETUP/TEARDOWN ACTIONS INA INFERENCE RULES 2-5A _________________________________________________A 2.5 MODIFYING THE SUFFIX LIST 2-5A _________________________________________________A 2.6 USING CONDITIONALS 2-6A iii   ContentsA _________________________________________________A 2.7 DEFERRING MACRO SUBSTITUTION 2-7A _________________________________________________A 2.8 MACRO STRING SUBSTITUTION 2-8A 2.8.1 Suffix Substitution ___________ 2-8A 2.8.2 General String Substitution ___ 2-8A _______________________________________________________A CHAPTER 3 USING DEC/CMS WITH MMK 3-1A _________________________________________________A 3.1 THE /CMS QUALIFIER 3-1A _________________________________________________A 3.2 EXPLICIT CMS ELEMENT REFERENCES 3-10 3.2.1 Specifying the ElementA Generation ____________________ 3-2A _________________________________________________A 3.3 INFERENCE RULES FOR CMS FILES 3-24 3.3.1 CMS and Prefixed InferenceA Rules _________________________ 3-3: MMK 3-4A _______________________________________________________A APPENDIX A DIFFERENCES BETWEEN MMK AND DEC/MMS A-1A _________________________________________________7 A.1 DEC/MMS FEATURES NOT SUPPORTED INA MMK A-1A _________________________________________________A A.2 MMK EXTENDED FEATURES A-2 iv  A ContentsA _________________________________________________A A.3 OTHER DIFFERENCES A-4A _______________________________________________________A APPENDIX B BUILT-IN DEPENDENCY RULES B-1A _______________________________________________________A APPENDIX C USING THE CROSS_ALPHA RULES C-1A _______________________________________________________ FIGURES8 B-1 MMK default dependency rules -A VAX ___________________________ B-18 B-2 MMK default dependency rules -A Alpha _________________________ B-9A _______________________________________________________ TABLESA C-1 MMK default suffix macros _____ C-1A C-2 CROSS_ALPHA suffix macros _____ C-1A v  A _______________________________________________________ Preface@ This guide explains how to install and use the MadGoat Make Utility (MMK).L __________________________________________________________________ Intended Audience> This manual is intended for all MMK users, primarily9 programmers who need to build software systems.: MMK is patterned after VAX DEC/Module Management> System (DEC/MMS), which is in turn based on the UNIX> make utility. The reader is assumed to have at least/ cursory knowledge of make or DEC/MMS.A Note: This document does not provide a general tutorial; on make utilities. New users are advised to learn? more about description files (makefiles) by reviewing@ either DEC/MMS documentation or books on the UNIX make utility.L __________________________________________________________________ Document Structure tbsL __________________________________________________________________ Related Documents tbsL __________________________________________________________________ Conventions< In this document, the following convention will be< used for the names of the three similar utilities:A o MMK refers to MadGoat Make, the package described in this document.> o DEC/MMS refers to DEC/Module Management System, a6 product of Digital Equipment Corporation.A vii   Preface2 o make refers to the UNIX make utility. viii  A _______________________________________________________ 1 Introduction@ This chapter describes MadGoat Make (MMK). It includes> an overview of MMK and basic information on its use.L __________________________________________________________________ 1.1 Overview> MMK is a tool for building a "software system;" that> is, a collection of one or more executable images or? other types of files that are related to a particular; project. Building a complex system by hand can be< a difficult and time-consuming task; using command? procedures can make the task easier, but it may still be time-consuming.> With MMK, you create a file called a Makefile or MMS@ description file to describe your software system: the? objects (i.e., source files, object files, etc.) that= comprise the system, the dependencies between those= objects, and the commands used to build the system.? When you invoke MMK, it performs the following steps:7 1 MMK reads and parses the description file,5 constructing a tree from the objects and- dependencies listed in the file.> 2 It then identifies the object to be built (called the target).@ 3 The tree of dependencies is traced from the target,> and the revision dates for the files in that path; are compared. If an object doesn't exist or isA older than the object it depends on, the commands to@ build the object are executed in a subprocess. This= continues until all objects along the dependency; path have been checked and the target has been+ brought completely up-to-date.A 1-1   Introduction> In this way, MMK can execute the commands to rebuild= only those pieces of your software system that need8 rebuilding due to a change that you have made.< This can drastically reduce development time for a project.L __________________________________________________________________ 1.2 Invoking MMK> Provided that MMK has been installed using the steps9 laid out in the installation instructions (file@ AAAREADME.INSTALL in the kit), you can invoke MMK from# DCL as a foreign command: $MMK> Full command syntax is given in MMK. By default, MMK< looks for a description file called DESCRIP.MMS in= the current directory; if that file does not exist,@ it then looks for a file called MAKEFILE. If it cannot? find that file, an error is signaled. You can use the@ /DESCRIPTION qualifier to specify a different name for+ your description file, if needed.8 MMK starts by reading the description file and< constructing a tree from the objects listed in the> description file (e.g., source files, include files,@ object files, etc.) and a tree of dependencies between= those objects. It then identifies the target object; to be built, and traverses the dependency tree to> identify those objects that need to be built (called= intermediate targets) in order to build the target.? MMK compares each target's revision date/time against: the objects on which it depends and executes the> actions for that building the target only if needed.> You can force a complete rebuild by using the /FROM_/ SOURCES qualifier on the MMK command. 1-2  A _______________________________________________________ 2 Description Files? The key to successfully building your software system= with MMK is the creation of a complete and accurate= description file. This chapter describes the format4 for a description file and its components.L __________________________________________________________________% 2.1 Description File Components= A description file is a collection of the following components:@ o Dependencies, which describe how one object depends* on one or more other objects.? o Actions, which are commands to be executed when an& object needs to be built.@ o Macro definitions, for defining symbols that may be& used in rules or actions.> o Inference rule definitions, which are rules basedA on suffixes (and possibly directories as well), fromA which MMK can infer dependencies and actions withoutA you having to list them explicitly in your makefile.= o MMK directives, which provide a means for adding8 commands to be executed before or after all> other actions, provide a simple conditional-build@ mechanism, and other directives for modifying MMK's behavior.A 2-1   Description Files: Here is an example of a simple description file:A PROGRAM.EXE : MAIN.OBJ,SUBROUTINES.OBJM LINK/EXEC=PROGRAM.EXE MAIN.OBJ,SUBROUTINES.OBJ. MAIN.OBJ : MAIN.FOR+ FORTRAN MAIN< SUBROUTINES.OBJ : SUBROUTINES.MAR0 MACRO SUBROUTINES9 This is a simple collection of dependencies and; actions for building an image called PROGRAM.EXE.9 PROGRAM.EXE depends on two object files, called@ MAIN.OBJ and SUBROUTINES.OBJ; MAIN is a FORTRAN module, and SUBROUTINES is a MACRO module.> MMK accepts either a colon or the DEC/MMS DEPENDS_ON? keyword to separate a target object from its sources.= In either case, the separator must be surrounded by? blanks-this differs from make, but is consistent with DEC/MMS syntax.L __________________________________________________________________ 2.2 Using Inference Rules? MMK includes a collection of built-in inference rules= and actions for most VMS programming languages. The> rules are driven by the file type suffix attached to> the object name; you must use the default file types4 in order to make use of the default rules.? For example, the description file in the last section& could be simplified to just:A PROGRAM.EXE : MAIN.OBJ,SUBROUTINES.OBJM LINK/EXEC=PROGRAM.EXE MAIN.OBJ,SUBROUTINES.OBJ. MAIN.OBJ : MAIN.FOR< SUBROUTINES.OBJ : SUBROUTINES.MAR= MMK's built-in inference rules automatically define: the actions for building a .OBJ file from a .FOR= (using the FORTRAN command) and for building a .OBJ: file from a .MAR file (using the MACRO command). 2-2  A Description Files@ The description file could even be simplified further, to just:A PROGRAM.EXE : MAIN.OBJ,SUBROUTINES.OBJM LINK/EXEC=PROGRAM.EXE MAIN.OBJ,SUBROUTINES.OBJ; MMK automatically searches the suffixes list whenM6 constructing the dependency tree and locates; inference rules for the .OBJ files automatically.(> This illustrates the second use for inference rules:: they are used not only for inferring actions for< a dependency that omits them, but they may also be? used for inferring dependencies themselves based on a1@ combination of source and target suffixes. This second@ purpose can greatly simplify your makefiles, and makes+ the build process more automatic.L __________________________________________________________________" 2.3 Defining Inference Rules< You can define your own inference rules, either to< extend or replace the ones built into MMK. You may@ include these rule definitions in your makefile, or in> a separate file called a rules file. Rules files can= be included by the use of a logical name or throughy> the /RULES qualifier on the MMK command; see the MMK" for further information.@ MMK supports two types of inference rules: generic and> prefixed. Generic rules are based solely on suffixes (file types), as in:# .C.OBJ :rD CC/OBJECT=$(MMS$TARGET) $(MMS$SOURCE)= which says, "to build filename.OBJ from an existing 9 file called filename.C, use the CC command." In > general, generic rules work best when the source and4 target files reside in the same directory.A 2-3a   Description Files= Prefixed inference rules are based on both suffixes_= and "prefixes"-device and directory specifications._= This provides a way to have MMK automatically infer = dependenices between files that reside in different_= directories. For example: For example, the prefixedI rule: 1 {SRC$:}.C{OBJ$:}.OBJ :_D CC/OBJECT=$(MMS$TARGET) $(MMS$SOURCE)8 tells MMK, "to build OBJ$:filename.OBJ from an: existing file called SRC$:filename.C, use the CC? command." This works like the generic rule above, but @ with the additional provision of having the source and/ target reside in different locations. 8 You can have more than one prefixed rule for a? particular pair of suffixes; you may also mix genericE? rules and prefixed rules for a pair of suffixes. When_: attempting to infer a dependency, MMK will first= use the prefixed rules, then fall back to using the_ generic rule._? In prefixed rules, the curly braces ("{" and "}") areS< required. One of the two prefixes may be null, but@ specifying two null prefixes is equivalent to defining a generic rule. ? In order to match a prefixed rule, file specification 9 as it exists in the description file must match9 the prefix in the rule; MMK performs no logical ; name translation on prefixes, nor can it identify_? equivalencies between two prefixes that reference the 0 same directory using different syntax.: The first inference rule for a pair of suffixes,< whether it is generic or prefixed, must specify an< action list; subsequent rules for the same pair of@ suffixes (with different prefixes) may have the action= list omitted, in which case MMK will use the action @ list from the first rule. For example, MMK already has7 a built-in generic rule for .C.OBJ, which is: 2-4  e aA Description Files_# .C.OBJ :P; $(CC)$(CFLAGS) $(MMS$SOURCE) > If you are simply adding a set of prefixed rules for? the .C.OBJ suffix pair, you do not need to specify an= action list on those rules; MMK will use the action_. list from the built-in generic rule.L __________________________________________________________________: 2.4 Forced Setup/Teardown Actions in Inference Rules> MMK recognizes two special modifiers on action lines< specified for inference rules. The setup modifier,= "<", forces the execution of an action prior to anyn? unmodified action. The teardown modifier, ">", forces = the execution of an action after all other actions.4: Setup and teardown actions are performed for all= dependencies matching the inference rule, even if aE/ dependency includes explicit actions._) For example, the inference rule # .C.OBJ :TN < DEFINE/USER DECC$SHR V6_ROOT:[SYSLIB]DECC$SHR= $(CC)$(CFLAGS) $(MMS$SOURCE)= would cause the logical name DECC$SHR to be defined-; prior to the invocation of the C compiler for all @ compilations into .OBJ files. This would apply even on; dependencies containing explicit actions, such as , FRED.OBJ : FRED.CE $(CC)$(CFLAGS)/DEFINE=FRED $(MMS$SOURCE)_L __________________________________________________________________# 2.5 Modifying the Suffix List_; MMK uses a suffix list to determine the inferenceR@ rules it should search for inferring a dependency. MMK= has a built-in suffix list which goes with its list > of built-in inference rules; see Appendix B for more< information on the built-in rules and suffix list.A 2-5    Description Files_8 You can augment or replace the built-in suffix< list with your own suffixes by using the .SUFFIXES2 directive in a rules file or a makefile.= For example, let's say you have a Modula-2 compiler= on your system, whose source files have a file type 9 (suffix) of .MOD. MMK has no built-in inference_> rules for this file type; you could add one with the following sequence:i+ .SUFFIXES : .MOD% .MOD.OBJ : I MODULA2/OBJECT=$(MMS$TARGET) $(MMS$SOURCE) < The .SUFFIXES directive above adds the .MOD suffix< to the end of the suffix list. This is followed by? the inference rule for creating an object file from aD Modula-2 source file.y@ Specifying the .SUFFIXES directive with nothing to the@ right of the colon clears the current suffix list. You= can do this to prevent MMK from using any inference ; rules for the current build, or to follow it witht? another .SUFFIXES directive that specifies only thosep; suffixes for which you want inference rules to beS enabled.L __________________________________________________________________ 2.6 Using Conditionals: MMK provides several directives that can be used; to modify the build sequence based on conditions._? These directives are .IF, .IFDEF, .IFNDEF, .ELSE, and? .ENDIF. The .IFDEF, .ELSE, and .ENDIF directives work_= the same as for MMS; the .IF and .IFNDEF directivesu< are MMK extensions. The .IFNDEF directive provides> the logical inverse to .IFDEF; the check succeeds if? the specified macro is not defined. The .IF directiveo: supports more general comparisons. Its syntax is 2-6   A Description Files E .IF "expression1" comparison "expression2"= where expression1 and expression2 can be any string6 that does not contain quotation marks. Macro; references may be used in the expressions as long = as the macro values do not contain quotation marks.1; The comparison operator is either EQL (equals) ord> NEQ (not equals). The quotation marks around the two= expressions are required. Comparisons are performed_- without regard to upper/lower case.L __________________________________________________________________& 2.7 Deferring Macro Substitution9 MMK provides a way to defer the resolution of aa< macro that is referenced in the right-hand side of< a macro definition, as an extension to MMS. Macros; are normally referenced using the $(name) syntax, ? which causes the value of the macro to be substituted= immediately when a line is parsed (except for MMK'sS? "special" macros, such as MMS$SOURCE and MMS$TARGET).e= You can defer this substitution in MMK by using the9 syntax ${name} instead. However, this syntax ish; only recognized on the right-hand side of a macroy= definition. This can be useful when defining macrosg= in a rules file that rely on macros that do not geti; defined until another rules file or a description> file gets processed. For example, you might have the/ following definition in a rules file:b CFLAGS = /OBJECT=$(MMS$TARGET)/NOLIST/DEFINE=(VMS_BUILD,${MOREDEFINES}); then in your description file, you can define the  MOREDEFINES macro:9 MOREDEFINES = ANOTHER_C_DEFINEi> This will complete the CFLAGS macro value when it is3 referenced later in the description file.sA 2-7  c  Description Files L __________________________________________________________________# 2.8 Macro String Substitution 8 MMK provides two mechanisms for causing string6 substitution to occur when resolving a macro; reference: suffix substitution and general stringd substitution.a% ___________________________r 2.8.1 Suffix Substitution ? When a string contains a list of file specifications,_= you can replace the file type suffixes on each file < specification with a different suffix. The general/ form of this type of substitution is:l8 $(macro-name:old-sfx=new-sfx)? which causes the replacement of all occurences of the > file type suffix old-sfx with new-sfx. Both suffixes must begin with a dot.2 For example, in these macro definitions:? SOURCES = FIRST.C, SECOND.C, THIRD.Ct7 OBJECTS = $(SOURCES:.C=.OBJ) < the OBJECTS macro would have the value "FIRST.OBJ,; SECOND.OBJ, THIRD.OBJ". This form of substitutionr: works with file specification lists separated by? either blanks, commas, or both. The substitution rulec@ following the colon may also contain blanks, which are6 ignored. Substitutions are case-insensitive.% ___________________________s% 2.8.2 General String Substitutionn< General string substitution in macro references is> an extended feature of MMK. It looks very similar to= suffix substitution, but uses a double colon ("::")n? instead of a single colon and allows the substitutiont= to occur anywhere within the string. The syntax is:i 2-8c s eA Description Files 9 $(macro-name::old-str=new-str)O? which causes the replacement of all occurences of the> string old-str with new-str. You may use a backslash@ "\" as a "literal-next" escape when one of the strings= contains an equals sign. Neither string may contain ? a right parenthesis character (")"), even quoted withe? a backslash, although this restriction will be lifted @ in a future release of MMK. For example, the following macro definitions:= SOURCES = FIRST.C,SECOND.C,THIRD.C7 SOURCEPLUS = $(SOURCES::,=+)l7 would cause SOURCEPLUS to contain the list of,? filenames separated with plus signs ("+") rather thanr commas.> General string substitutions in macro references are; case-insensitive, but do not ignore blanks in thed? macro value or in the substitution rule. For example,n' in the following definitions:n2 TEST = Xyz xYz xyZ7 REPLACED = $(TEST::YZ =YZ,)@ the REPLACED macro would have the value "XYZ,xYZ,xyZ",@ due to the case-blind comparisons and the inclusion of1 the space in the old-str specification.aA 2-9h a oA _______________________________________________________s 3 Using DEC/CMS with MMK> This chapter describes the use of Digital's DEC/Code/ Management System (DEC/CMS) with MMK.iL __________________________________________________________________ 3.1 The /CMS Qualifier: The MMK command supports a /CMS qualifier, which: activates the automatic use of the currently set: DEC/CMS library, or another DEC/CMS library that9 you specify, for the current build. This causesT? source files to be fetched out of the DEC/CMS libraryS8 automatically, if needed. In addition, the MMK< description file will automatically be fetched out6 of the DEC/CMS library if it does not exist.: The built-in suffix list and dependency rules in= MMK include default rules for fetching source filesd> out of DEC/CMS libraries. Suffixes ending in a tilde? character ("~") signify DEC/CMS library elements. Theu> built-in DEC/CMS element rules are used only if /CMS* is specified on the MMK command.L __________________________________________________________________) 3.2 Explicit CMS Element References_? You can explicitly reference a CMS library element inl@ your MMK description file by adding a tilde to the end1 of the file specification. For example: 1 MAIN.FOR : MAIN.FOR~ ; You can also explicitly name the CMS library fromp> which the element should be fetched, by specifying a' device and/or directory name:nI MAIN.FOR : SOURCE_DISK:[CMS_SOURCE]MAIN.FOR~ A 3-1   Using DEC/CMS with MMK< If you do not explicitly name the CMS library, the> currently set CMS library (set with CMS SET LIBRARY) will be used.e% ___________________________h+ 3.2.1 Specifying the Element Generation> By default, MMK uses the qualifier /GENERATION=1+ on? all CMS FETCH operations, to get the highest-numbered : generation of a particular element, or whichever7 generation you specify on the MMK /GENERATIONc; qualifier. If you need to build a dependency on aj= specific generation of an element, you may do so byU@ specifying the /GENERATION qualifier on the file name:? MAIN.FOR : MAIN.FOR~/GENERATION=37e< The above example would cause generation 37 of the= MAIN.FOR file in the current CMS library to be usedm for the build.L __________________________________________________________________' 3.3 Inference Rules for CMS Filese> MMK comes with built-in inference rules for fetching< source files from a CMS library. Like DEC/MMS, MMK9 uses these rules only when you specify the /CMS ? qualifier on the MMK command. This allows you to have ( a makefile like the following:. TEST.EXE : TEST.OBJ@ $(LINK)$(LINKFLAGS) $(MMS$SOURCE). TEST.OBJ : TEST.FOR@ If you have a CMS library set and you specify the /CMS> qualifier on the MMK command, MMK will automatically= check to see if TEST.FOR resides in the CMS libraryl9 and will fetch it out of the library if needed.o9 However, MMK also allows you to omit the second;< dependency in the makefile, and will automatically@ "double-infer" the existence the .FOR file, even if it: has not yet been fetched out of the CMS library. 3-2  i A Using DEC/CMS with MMKC% ___________________________ * 3.3.1 CMS and Prefixed Inference Rules< You can have MMK automatically search specific CMS@ libraries for source files by using prefixed inference= rules. For example, if you were working on a cross- 9 platform development project which used two CMS-9 libraries - one for OS-specific source code and < another for common source code - you might use the# following prefixed rules:e? {CMSSRC:[VMS_SPECIFIC]}.FOR~{}.FOR :u9 {CMSSRC:[COMMON]}.FOR~{}.FOR :a? This sequence would cause MMK to automatically searchm= the CMSSRC:[VMS_SPECIFIC] CMS library for a FORTRAN ? source file, then search the CMSSRC:[COMMON] library.E9 If the file were not located in either library,b< MMK would fall back to using the currently set CMS< library. You must still have a CMS library set and> you must specify the /CMS qualifier for prefixed CMS& inference rules to be tried.A 3-3a  MMK A _______________________________________________________r MMKe= Invokes the MMK utility to build a software system.rA _______________________________________________________  FORMAT MMK [target-name ...]A _______________________________________________________o) Command Qualifiers Defaultsf( /[NO]ACTION /ACTION0 /[NO]CHECK_STATUS /NOCHECK_STATUS' /[NO]CMS /NOCMSf$ /CMS_LIBRARY=(dir-spec...) /DESCRIPTION=file-spec /DUMPx) /[NO]FORCE /NOFORCE 0 /[NO]FROM_SOURCES /NOFROM_SOURCES1 /GENERATION=string /GENERATION="1+"s /IDENTIFICATION * /[NO]IGNORE[=level] /NOIGNORE- /[NO]LOCAL_RULES /LOCAL_RULES ' /[NO]LOG /NOLOGe* /MACRO=file-spec | definition... /OUTPUT=file-spec , /[NO]OVERRIDE /NOOVERRIDE& /[NO]RULES_FILE=file-spec...5 /[NO]SKIP_INTERMEDIATE/NOSKIP_INTERMEDIATESe( /[NO]VERIFY /VERIFY% /WORKING_DIRECTORY=dir-spec A _______________________________________________________ PARAMETERS target-name > Name of the target to be built. The target name must> be listed in the description file. If no target name< is specified, MMK builds the first target it finds 3-4  A MMKi: in the description file. Multiple targets may be. specified as a comma-separated list.A _______________________________________________________  DESCRIPTIONc; The MMK utility builds a software system from thei@ objects and dependencies listed in a description file.; See the documentation for additional information. A _______________________________________________________  QUALIFIERS /[NO]ACTION > Determines whether action lines are executed or just? displayed. Specifying /NOACTION causes MMK to displayn> the action lines that would be executed to build the2 target, without actually executing them. /[NO]CHECK_STATUS = Directs MMK to determine whether a target is up-to-S@ date, without executing any action lines to do so. MMK> sets the global symbol MMS$STATUS to 0 if the target> requires updating, or 1 if the target is up-to-date.9 This qualifier overrides the /ACTION qualifier.i /[NO]CMS9 Determines whether a DEC/Code Management Systemc= (CMS) library is automatically searched for the MMKR@ description file and for any source files. The default0 is /NOCMS, which omits any CMS checks.$ /CMS_LIBRARY=(dir-spec...)@ Specifies one or more DEC/Code Management System (CMS)? libraries to be searched for the MMK description file @ and for any source files that do not have explicit CMS= library specifications. Effective only when /CMS ise= also specified. If omitted, the default CMS libraryt@ or libraries (from the logical name CMS$LIB or the CMS( SET LIBRARY command) are used.A 3-5u n r MMKi /DESCRIPTION=file-spec? Specifies an alternative name for the MMK descriptionr@ file. The default description file name is DESCRIP.MMS< (in the current default directory), with MAKEFILE.3 being used if DESCRIP.MMS does not exist.o /DUMP_; Causes MMK to dump the suffix list, all currentlyt6 defined macros, all inference rules, and all@ dependencies to the current output before starting the? build. This qualifier is useful in debugging problems(' in rules files and makefiles.i /[NO]FORCE: Specifying /FORCE causes MMK to execute only the? action lines from the dependency rule for the target, 9 without performing any revision date checks and 4 without building any intermediate targets. /[NO]FROM_SOURCESc: Specifying /FROM_SOURCES causes MMK to perform a@ complete build of the target, ignoring revision dates.; All actions to build all intermediate targets areE executed.i /GENERATION=string> Specifies the default generation to be used when MMK< fetches elements out of a CMS library. If omitted,; the default generation is "1+", which fetches the < highest-numbered generation of an element. You can< use this qualifier in combination with CMS classes? to have MMK build a specific version of your software > system, provided that all source code for the system/ is fetched from CMS during the build.c /IDENTIFICATIONe> Specifying /IDENTIFICATION causes MMK to display its? revision information and a copyright message, withouta& performing any other action. 3-6s r eA MMK  /[NO]IGNORE[=level]e< By default, MMK stops when an executed action line= results in a warning, error, or fatal error status.i< You can override this by specifying /IGNORE. Using: /IGNORE or /IGNORE=FATAL causes all errors to be= ignored; specifying /IGNORE=ERROR causes errors ande< warnings to be ignored; specifying /IGNORE=WARNING- causes only warnings to be ignored.E /[NO]LOCAL_RULES7 Controls whether site-specific inference rule > definitions are read in. By default, they are if the? logical name MMK_LOCAL_RULES is defined and points to_@ a readable description file. Specifying /NOLOCAL_RULES' prevents this from occurring.  /[NO]LOG= Controls whether MMK logs a detailed description of 0 its activity. By default, it does not.+ /MACRO=file-spec | definintion...n> Defines one or more macros that can be referenced by> the description file. If a name is specified with no= equals sign ("="), it is first assumed to be a fileM> specification; if the file exists, macro definitions@ are read from the file. A file type of .MMS is assumed= if no file type is specified. If the file cannot beh? found, the name is treated as macro definition, and ae9 value of 1 is assigned to the macro by default.m? If an equals sign is present, the macro definition iso/ taken directly from the command line.F? Macro definitions contained in a file should have the @ same syntax as macro definitions in description files,< with the added restrictions that comments and line( continuations are not allowed. /OUTPUT=file-spec 9 Directs MMK output to a location other than theC default, SYS$OUTPUT.A 3-7r  MMK /[NO]OVERRIDE < Determines the order in which macro references are? resolved. The default order is to resolve macros from_> command-line definitions, followed by definitions in? the description file and any rules files, followed byi? MMK built-ins. If a macro cannot be resolved from any < of these sources, a check is made for a DCL symbol> with the same name as the macro, and if present, the! symbol's value is used. > When /OVERRIDE is specified, DCL symbols are checked= before the macro definitions in the description and : rules files, and before the MMK built-in macros.( /[NO]RULES_FILE[=file-spec...]7 Specifies the name of one or more descriptione: files containing inference rules. If /RULES_FILE; is specified with no file specification, the namef= MMS$RULES is used by default (this can be a logical > name or can reference a file called MMS$RULES.MMS in! the current directory). @ If /NORULES_FILE is specified, the compiled-in default> rules are not loaded when MMK is started, nor is any= personal rules file (pointed to by the logical name = MMK_PERSONAL_RULES). /NORULES_FILE does not prevent ; the loading of local rules; you must also specify : /NOLOCAL_RULES to prevent local rules from being loaded.e! /[NO]SKIP_INTERMEDIATES.: By default, MMK attempts to build missing source< files if they can be built through the application= of dependency or inference rules. Specifying /SKIP_K9 INTERMEDIATES causes MMK to treat these missingb= sources as if they exist and have the same revisiono= date/time stamp as the target that depends on them.i 3-8s a sA MMK 9 For example, if the target is a .EXE file whichm< depends on a .OBJ file, and that .OBJ file in turn= depends on a .C file, by default MMK will build thet@ .OBJ file if it is missing, and then in turn build the@ .EXE. If /SKIP_INTERMEDIATES is specified, the missing< .OBJ file will not trigger a build; the build will@ only occur if the .C file is newer than the .EXE file. /[NO]VERIFY 5 Controls whether MMK echoes action lines tox) SYS$OUTPUT. Enabled by default.i% /WORKING_DIRECTORY=dir-specC> Causes MMK to SET DEFAULT to the specified directory: before processing the description file. This can: be useful when using the /NOACTION qualifier for: a build in a directory containing subdirectories> with their own description files, since only actions> invoking $(MMS) get executed when /NOACTION is used.# By replacing the actions:r8 SET DEFAULT [.subdirectory]4 $(MMS) $(MMSQUALIFIERS) with the actionRV $(MMS) $(MMSQUALIFIERS)/WORKING_DIRECTORY=[.subdirectory]= the entire multi-directory build can be tested withs! /NOACTION successfully.oA 3-9   A ________________________________________________________- A Differences between MMK and DEC/MMSM< MMK is patterned after DEC/MMS, but does not fully@ implement all DEC/MMS functionality and provides other= extended functionality. This appendix lists some of_2 the differences between MMK and DEC/MMS.= Besides the differences in features, there are some ; differences in processing between MMK and DEC/MMSE> which may lead to different results or syntax errors= in MMK for description files which operate properlyl< under DEC/MMS. If possible, please report any such> differences to the author so that they can be fixed.L __________________________________________________________________/ A.1 DEC/MMS Features Not Supported in MMKt> MMK does not support the following DEC/MMS features:8 o MMK does not support FMS forms libraries or& CDD/Repository libraries.8 o MMK does not honor the "; action" syntax onA dependency rule lines that can be used with DEC/MMS. 9 Make sure all actions are on separate lines._9 o MMK requires the leading dot on the .INCLUDE2 directive.R; o MMK does not handle wildcard dependency rules.a? o MMK does not support all of the command qualifiersd9 supported by DEC/MMS. In addition, the MMK'sp? /GENERATION qualifier is completely different from + DEC/MMS's /GENERATE qualifier.b6 o MMK does not have a DECwindows interface.A A-1   - Differences between MMK and DEC/MMSN? o MMK does not automatically load the MMS$RULES file @ if that logical name is defined or that file exists> in the current directory; you must specify /RULES? on the MMK command to have it loaded. Use the MMK_i? LOCAL_RULES or MMK_PERSONAL_RULES logical names to14 have rules automatically loaded by MMK.L __________________________________________________________________ A.2 MMK Extended Features: MMK includes the following features not found in DEC/MMS:? o MMK gives you more options for rules files, and isd@ set up to allow multiple rules files to be present.8 Rule file processing follows this sequence:= 1 The default rules compiled into MMK are loadedM> automatically unless /NORULES_FILE is specified" on the MMK command.8 2 A site-defined local rules file is loaded@ automatically if the logical name MMK_LOCAL_RULES; is defined (use /NOLOCAL_RULES to override).e= 3 If the /RULES_FILE qualifier is specified, anyn; rules files listed there are loaded; if none : are listed, the default is to load the file; MMS$RULES.MMS (or the file pointed to by them' logical name MMS$RULES). 9 If the /RULES_FILE qualifier is omitted, aT; personal rules file is loaded if the logicalI? name MMK_PERSONAL_RULES is defined. MMS$RULES isE' not loaded in this case.r? If /NORULES_FILE is specified, neither MMS$RULESm5 nor the personal rules file is loaded. > These rules-processing features, coupled with the? ability to redefine macros defined in rules files,o< make it easier to customize MMK's behavior when needed. A-2d l nA Differences between MMK and DEC/MMSn8 o MMK trims blanks out of $(MMS$SOURCE_LIST).A o MMK includes support for the following special local macros:; o $(MMS$SOURCE_LIST_SPACES) - source list withs6 spaces as separators instead of commas.; o $(MMS$CHANGED_LIST_SPACES) - list of changedd; sources with spaces as separators instead of  commas.@ o $(MMS$SOURCE_NAME) - like $(MMS$TARGET_NAME), but! for $(MMS$SOURCE). = o $(MMS$TARGET_FNAME) - like $(MMS$TARGET_NAME),e8 but does not include the device/directory0 specification, just the filename.> o $(MMS$TARGET_MODULE) - name of the module being9 replaced in a text, help, macro, or objectm library.M> o MMK will display activity in the subprocess while; action lines are being executed when you press  CTRL/T./ o MMK allows you to redefine macros.i? o MMK, in most cases, has more flexible syntax rulesCA for its description files, allowing blanks where MMSo? does not (e.g., in library module specifications).; o MMK pre-defines the macros __VAX__ for builds < on VAX systems and __AXP__ for builds on Alpha systems._@ o MMK supports prefixed inference rules (described in Section 2.3).> o When used with DEC/CMS, MMK will "double-infer" a> dependency on a non-existent source file, if that5 file currently resides in a CMS library._9 o MMK includes a /DUMP qualifier for debuggingm% problems with makefiles. A A-3O C T- Differences between MMK and DEC/MMS < o MMK provides a /GENERATION qualifier on the MMKA command for specifying the default CMS generation to @ be used when elements are checked for revisions and fetched out of CMS.; o MMK provides the /WORKING_DIRECTORY qualifier.< o MMK allows "generic" targets (those that do not@ refer to an actual file) to have null action lists.= MMS requires all targets to have an action list. A o MMK adds the ${name} syntax for deferring resolutionO8 of macros on the right-hand side of a macro definition.A o MMK adds a generic string-susbstitution function for_ macro references.? o MMK adds the .IFNDEF and .IF directives to make ita- easier to conditionalize builds.u? You should avoid using these extended features if you6 need to maintain compatibility with DEC/MMS.L __________________________________________________________________ A.3 Other Differences? Besides the feature differences alrady mentioned, MMK ? operates somewhat differently from DEC/MMS in some of_> its processing. In most cases, these differences are@ not significant, but they are worth remembering if you@ need to port DEC/MMS description files to or from MMK.> o MMK allows any rule, including built-in rules, toA override the .DEFAULT actions. DEC/MMS lets .DEFAULT - actions override built-in rules. : o When a build action does not update a target,> MMK will issue an information message, except for? generic targets. DEC/MMS only issues such messagest in certain cases. A-4t . A Differences between MMK and DEC/MMSr@ o MMK explicitly builds dependency rules for files on> which library modules depend, even if those files< are not mentioned in the description file. This? may lead to MMK behaving differently from DEC/MMS,iA although if the description file is correct, the endd% result will be the same.i7 o MMK parses comments and continuation linesc: differently, so that a hyphen at the end of a< comment is not considered a continuation of the comment. : As other differences are brought to the author's= attention, they will either be fixed or noted here. A A-5e C iA _______________________________________________________b# B Built-in Dependency Rulesr@ The dependency rules built into MMK for VAX systems is> given in Figure B-1. The dependency rules built into7 MMK for Alpha systems is given in Figure B-2.8 Figure B-1 MMK default dependency rules - VAXA _______________________________________________________M! ! MMK_DEFAULT_RULES.MMS !iS ! COPYRIGHT © 1993, 1994, 1997 MADGOAT SOFTWARE. ALL RIGHTS RESERVED._ !aE ! Default build rules for use with MMK. (for VAX systems)r !e" ! Modification history: ! : ! 23-DEC-1992 V1.0 Madison Initial coding.P ! 17-OCT-1993 V1.1 Madison Elimination of intermediate libfiles.F ! 11-APR-1994 V1.2 Madison Make rules more like MMS's.; ! 01-JUL-1994 V2.0 Madison Add CMS support. ; ! 16-JUL-1994 V2.1 Madison Update for V3.2.aL ! 22-AUG-1994 V2.1-1 Madison Eliminate DELETE_SOURCE checks.; ! 14-OCT-1994 V2.2 Madison Add CXX support.uC ! 28-DEC-1994 V2.3 Madison Make IF commands silent.gI ! 20-JUN-1997 V2.3-1 Madison Add .MAR.MLB inference rule.r ! A _______________________________________________________e( Figure B-1 Cont'd on next pageA B-1  e i# Built-in Dependency Rules @ Figure B-1 (Cont.) MMK default dependency rules - VAXA _______________________________________________________ !iS ! These symbols can be used to distinguish MMK from DEC's DEC/MMS product$ ! using .IFDEF directives. !' __MATTS_MMS__ = __MATTS_MMS__c __MMK__ = __MMK__  __MMK_V32__ = 1 !rL ! This symbol can be used to distinguish a VAX-based build from anE ! AXP-based build. (or use .IFDEF __AXP__ .ELSE ... .ENDIF) !  __VAX__ = 1 EXE = .EXE OLB = .OLB OBJ = .OBJ OPT = .OPT L32 = .L327 .SUFFIXES : ! clear the suffix list firsto^ .SUFFIXES : $(EXE) $(OLB) $(OBJ) .TLB .HLB .MLB $(L32) .C .CXX .BAS .B32 .BLI .FOR -U .COB .COR .DBL .RPG .SCN .PLI .PEN .PAS .MAC .MAR .MSG .CLD .R32 - O .REQ .TXT .H .MEM .HLP .RNH .RNO .MMS .DAT .OPT .SDML .COM -sT .C~ .CXX~ .BAS~ .B32~ .BLI~ .FOR~ .COB~ .COR~ .DBL~ .RPG~ .SCN~ -J .PLI~ .PAS~ .MAC~ .MAR~ .MSG~ .CLD~ .R32~ .REQ~ .TXT~ -G .H~ .HLP~ .RNH~ .RNO~ .MMS~ .DAT~ .OPT~ .SDML~ .COM~ LINK = LINKi+ LINKFLAGS = /EXEC=$(MMS$TARGET)  $(OBJ)$(OLB) :W @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE $(MMS$TARGET)= $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)M .TXT.TLB :\ @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/TEXT $(MMS$TARGET)Y $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)/MODULE=$(MMS$TARGET_MODULE)dA _______________________________________________________f( Figure B-1 Cont'd on next page B-2.  aA Built-in Dependency Rules@ Figure B-1 (Cont.) MMK default dependency rules - VAXA _______________________________________________________a .HLP.HLB :\ @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/HELP $(MMS$TARGET)= $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)a .MAC.MLB :] @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/MACRO $(MMS$TARGET) = $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)s .MAR.MLB :] @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/MACRO $(MMS$TARGET) = $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)  LIBR = LIBRARY LIBRFLAGS = /REPLACE .BAS$(OBJ) :/ $(BASIC)$(BASFLAGS) $(MMS$SOURCE)  BASIC = BASICo? BASFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)n .BLI$(OBJ) :- $(BLISS)$(BFLAGS) $(MMS$SOURCE)  .B32$(OBJ) :- $(BLISS)$(BFLAGS) $(MMS$SOURCE)f> BFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ) .C$(OBJ) :* $(CC)$(CFLAGS) $(MMS$SOURCE) CC = CC > CFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ) .COB$(OBJ) :/ $(COBOL)$(COBFLAGS) $(MMS$SOURCE)i COBOL = COBOL-? COBFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ) A _______________________________________________________i( Figure B-1 Cont'd on next pageA B-3M U # Built-in Dependency Rules @ Figure B-1 (Cont.) MMK default dependency rules - VAXA _______________________________________________________e .COR$(OBJ) :/ $(CORAL)$(CORFLAGS) $(MMS$SOURCE)t CORAL = CORALs? CORFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)E .CXX$(OBJ) :- $(CXX)$(CXXFLAGS) $(MMS$SOURCE)l CXX = CXX? CXXFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)i .DBL$(OBJ) :/ $(DIBOL)$(DBLFLAGS) $(MMS$SOURCE)d DIBOL = DIBOL ? DBLFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)a .CLD$(OBJ) :3 $(SETCMD)$(SETCMDFLAGS) $(MMS$SOURCE) " SETCMD = SET COMMAND? SETCMDFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)h .FOR$(OBJ) :, $(FORT)$(FFLAGS) $(MMS$SOURCE) FORT = FORTRANa? FFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  .MAR$(OBJ) :- $(MACRO)$(MFLAGS) $(MMS$SOURCE)  MACRO = MACROa> MFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ) .MSG$(OBJ) :1 $(MESSAGE)$(MSGFLAGS) $(MMS$SOURCE)  MESSAGE = MESSAGE ? MSGFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ) A _______________________________________________________y( Figure B-1 Cont'd on next page B-4   OA Built-in Dependency Rules @ Figure B-1 (Cont.) MMK default dependency rules - VAXA _______________________________________________________y .PAS$(OBJ) :. $(PASCAL)$(PFLAGS) $(MMS$SOURCE) .PAS.PEN :1 $(PASCAL)$(PENVFLAGS) $(MMS$SOURCE)c PASCAL = PASCAL> PFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)B PENVFLAGS = /ENVIRONMENT=$(MMS$TARGET_NAME).PEN/NOLIST .PLI$(OBJ) :- $(PLI)$(PLIFLAGS) $(MMS$SOURCE)U PLI = PLI? PLIFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)t .REQ$(L32) :N $(BLISS)/LIBR=$(MMS$TARGET_NAME)$(L32)$(BLIBFLAGS) $(MMS$SOURCE) .R32$(L32) :N $(BLISS)/LIBR=$(MMS$TARGET_NAME)$(L32)$(BLIBFLAGS) $(MMS$SOURCE) BLISS = BLISS  BLIBFLAGS = /NOLIST  .RPG$(OBJ) :- $(RPG)$(RPGFLAGS) $(MMS$SOURCE)_ RPG = RPG? RPGFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ) .RNH.HLP :. $(RUNOFF)$(RFLAGS) $(MMS$SOURCE) .RNO.MEM :. $(RUNOFF)$(RFLAGS) $(MMS$SOURCE) RUNOFF = RUNOFFi, RFLAGS = /OUTPUT=$(MMS$TARGET)A _______________________________________________________e( Figure B-1 Cont'd on next pageA B-5n e t# Built-in Dependency Rulesd@ Figure B-1 (Cont.) MMK default dependency rules - VAXA _______________________________________________________o .SCN$(OBJ) :/ $(SCAN)$(SCANFLAGS) $(MMS$SOURCE)_ SCAN = SCAN_? SCANFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  CMS = CMS CMSCOMMENT = ""2 CMSFLAGS = /GENERATION=$(MMS$CMS_GEN) .B32~.B32 :pY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY) c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).B32 $(CMSFLAGS) $(CMSCOMMENT)a .BAS~.BAS : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Mc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).BAS $(CMSFLAGS) $(CMSCOMMENT)d .BLI~.BLI : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)ec $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).BLI $(CMSFLAGS) $(CMSCOMMENT)a .C~.C :.Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY) a $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).C $(CMSFLAGS) $(CMSCOMMENT)M .CLD~.CLD : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)rc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).CLD $(CMSFLAGS) $(CMSCOMMENT)  .COB~.COB :EY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY) c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COB $(CMSFLAGS) $(CMSCOMMENT)a .COR~.COR :nY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)uc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COR $(CMSFLAGS) $(CMSCOMMENT)n .COM~.COM :eY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)ec $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COM $(CMSFLAGS) $(CMSCOMMENT)oA _______________________________________________________ ( Figure B-1 Cont'd on next page B-6L  A Built-in Dependency Rules @ Figure B-1 (Cont.) MMK default dependency rules - VAXA _______________________________________________________t .CXX~.CXX : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)nc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).CXX $(CMSFLAGS) $(CMSCOMMENT)a .DAT~.DAT : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY) c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).DAT $(CMSFLAGS) $(CMSCOMMENT)  .DBL~.DBL :aY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).DBL $(CMSFLAGS) $(CMSCOMMENT)o .FOR~.FOR :Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)ec $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).FOR $(CMSFLAGS) $(CMSCOMMENT)  .H~.H : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ca $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).H $(CMSFLAGS) $(CMSCOMMENT)  .HLP~.HLP :SY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).HLP $(CMSFLAGS) $(CMSCOMMENT)  .MAC~.MAC :Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)oc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MAC $(CMSFLAGS) $(CMSCOMMENT)M .MAR~.MAR :oY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY) c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MAR $(CMSFLAGS) $(CMSCOMMENT)i .MMS~.MMS :eY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY) c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MMS $(CMSFLAGS) $(CMSCOMMENT)s .MSG~.MSG :MY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)ec $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MSG $(CMSFLAGS) $(CMSCOMMENT)aA _______________________________________________________n( Figure B-1 Cont'd on next pageA B-7e a # Built-in Dependency Ruleso@ Figure B-1 (Cont.) MMK default dependency rules - VAXA _______________________________________________________  .OPT~.OPT :kY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).OPT $(CMSFLAGS) $(CMSCOMMENT)l .PAS~.PAS : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)nc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).PAS $(CMSFLAGS) $(CMSCOMMENT)W .PLI~.PLI :rY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)nc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).PLI $(CMSFLAGS) $(CMSCOMMENT)t .R32~.R32 :dY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)dc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).R32 $(CMSFLAGS) $(CMSCOMMENT)o .REQ~.REQ :oY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY) c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).REQ $(CMSFLAGS) $(CMSCOMMENT)o .RNH~.RNH :nY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)_c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNH $(CMSFLAGS) $(CMSCOMMENT)a .RNO~.RNO : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)sc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNO $(CMSFLAGS) $(CMSCOMMENT)  .SCN~.SCN :SY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)rc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).SCN $(CMSFLAGS) $(CMSCOMMENT)e .SDML~.SDML : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)fd $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).SDML $(CMSFLAGS) $(CMSCOMMENT) .TXT~.TXT :Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)/c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).TXT $(CMSFLAGS) $(CMSCOMMENT)lA _______________________________________________________i( Figure B-1 Cont'd on next page B-8o K hA Built-in Dependency Rulesi@ Figure B-1 (Cont.) MMK default dependency rules - VAXA _______________________________________________________ A _______________________________________________________t: Figure B-2 MMK default dependency rules - AlphaA _______________________________________________________ % ! MMK_DEFAULT_RULES_AXP.MMSx !eM ! COPYRIGHT © 1993, 1997 MADGOAT SOFTWARE. ALL RIGHTS RESERVED. ! E ! Default build rules for use with MMK. (for OpenVMS AXP)_ !_" ! Modification history: ! : ! 23-DEC-1992 V1.0 Madison Initial coding.H ! 17-OCT-1993 V1.1 Madison Delete intermediate libfiles.F ! 11-APR-1994 V1.2 Madison Make rules more like MMS's.; ! 05-JUL-1994 V2.0 Madison Add CMS support.y; ! 16-JUL-1994 V2.1 Madison Update for V3.2._L ! 22-AUG-1994 V2.1-1 Madison Eliminate DELETE_SOURCE checks.; ! 14-OCT-1994 V2.2 Madison Add CXX support.RC ! 28-DEC-1994 V2.3 Madison Make IF commands silent.uI ! 20-JUN-1997 V2.3-1 Madison Add .MAR.MLB inference rule.i ! A _______________________________________________________ ( Figure B-2 Cont'd on next pageA B-9o l # Built-in Dependency Rulesd< Figure B-2 (Cont.) MMK default dependency rules -# AlphaAA _______________________________________________________ !9Q ! This symbol can be used to distinguish MMK from DEC's DEC/MMS productk$ ! using .IFDEF directives. !2' __MATTS_MMS__ = __MATTS_MMS__u __MMK__ = __MMK__  __MMK_V32__ = 1_ !_N ! These symbols can be used to distinguish an AXP-based build from a ! VAX-based build. !  __ALPHA__ = 1 __AXP__ = 1n EXE = .EXE OLB = .OLB OBJ = .OBJ OPT = .OPT L32 = .L327 .SUFFIXES : ! clear the suffix list first^ .SUFFIXES : $(EXE) $(OLB) $(OBJ) .TLB .HLB .MLB $(L32) .C .CXX .BAS .B32 .BLI .FOR -U .COB .COR .DBL .RPG .SCN .PLI .PEN .PAS .MAC .MAR .M64 .MSG .CLD - T .R32 .REQ .TXT .H .MEM .HLP .RNH .RNO .MMS .DAT .OPT .SDML .COM -T .C~ .CXX~ .BAS~ .B32~ .BLI~ .FOR~ .COB~ .COR~ .DBL~ .RPG~ .SCN~ -P .PLI~ .PAS~ .MAC~ .MAR~ .M64~ .MSG~ .CLD~ .R32~ .REQ~ .TXT~ -G .H~ .HLP~ .RNH~ .RNO~ .MMS~ .DAT~ .OPT~ .SDML~ .COM~  LINK = LINK + LINKFLAGS = /EXEC=$(MMS$TARGET)a $(OBJ)$(OLB) :W @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE $(MMS$TARGET)R= $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE).A _______________________________________________________ ( Figure B-2 Cont'd on next page B-10 . ~A Built-in Dependency Rules < Figure B-2 (Cont.) MMK default dependency rules -# Alpha~A _______________________________________________________  .TXT.TLB :\ @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/TEXT $(MMS$TARGET)Y $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)/MODULE=$(MMS$TARGET_MODULE)O .HLP.HLB :\ @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/HELP $(MMS$TARGET)= $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)O .MAC.MLB :] @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/MACRO $(MMS$TARGET)u= $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)  .MAR.MLB :] @ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/MACRO $(MMS$TARGET)n= $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)_ LIBR = LIBRARY LIBRFLAGS = /REPLACE .BAS$(OBJ) :/ $(BASIC)$(BASFLAGS) $(MMS$SOURCE)  BASIC = BASIC ? BASFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  .BLI$(OBJ) :- $(BLISS)$(BFLAGS) $(MMS$SOURCE)$ .B32$(OBJ) :- $(BLISS)$(BFLAGS) $(MMS$SOURCE)s> BFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ) .C$(OBJ) :* $(CC)$(CFLAGS) $(MMS$SOURCE) CC = CC(> CFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)A _______________________________________________________ ( Figure B-2 Cont'd on next pageA B-11T E A# Built-in Dependency Rules < Figure B-2 (Cont.) MMK default dependency rules -# AlphaOA _______________________________________________________B .COB$(OBJ) :/ $(COBOL)$(COBFLAGS) $(MMS$SOURCE)  COBOL = COBOL ? COBFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  .COR$(OBJ) :/ $(CORAL)$(CORFLAGS) $(MMS$SOURCE)  CORAL = CORAL ? CORFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  .CXX$(OBJ) :- $(CXX)$(CXXFLAGS) $(MMS$SOURCE)u CXX = CXX? CXXFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  .DBL$(OBJ) :/ $(DIBOL)$(DBLFLAGS) $(MMS$SOURCE)i DIBOL = DIBOL ? DBLFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)_ .CLD$(OBJ) :3 $(SETCMD)$(SETCMDFLAGS) $(MMS$SOURCE)F" SETCMD = SET COMMAND? SETCMDFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)E .FOR$(OBJ) :, $(FORT)$(FFLAGS) $(MMS$SOURCE) FORT = FORTRAN ? FFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)E .MAR$(OBJ) :- $(MACRO)$(MFLAGS) $(MMS$SOURCE)M% MACRO = MACRO/MIGRATION > MFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)A _______________________________________________________(( Figure B-2 Cont'd on next page B-12 C LA Built-in Dependency Rules:< Figure B-2 (Cont.) MMK default dependency rules -# AlphaNA _______________________________________________________  .M64$(OBJ) :/ $(TASM)$(TASMFLAGS) $(MMS$SOURCE) TASM = MACRO? TASMFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  .MSG$(OBJ) :1 $(MESSAGE)$(MSGFLAGS) $(MMS$SOURCE)G MESSAGE = MESSAGES? MSGFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)_ .PAS$(OBJ) :. $(PASCAL)$(PFLAGS) $(MMS$SOURCE) .PAS.PEN :1 $(PASCAL)$(PENVFLAGS) $(MMS$SOURCE)  PASCAL = PASCAL> PFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)B PENVFLAGS = /ENVIRONMENT=$(MMS$TARGET_NAME).ENV/NOLIST .PLI$(OBJ) :- $(PLI)$(PLIFLAGS) $(MMS$SOURCE)S PLI = PLI? PLIFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  .REQ$(L32) :N $(BLISS)/LIBR=$(MMS$TARGET_NAME)$(L32)$(BLIBFLAGS) $(MMS$SOURCE) .R32$(L32) :N $(BLISS)/LIBR=$(MMS$TARGET_NAME)$(L32)$(BLIBFLAGS) $(MMS$SOURCE) BLISS = BLISS  BLIBFLAGS = /NOLISTS .RPG$(OBJ) :- $(RPG)$(RPGFLAGS) $(MMS$SOURCE) RPG = RPG? RPGFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)RA _______________________________________________________B( Figure B-2 Cont'd on next pageA B-13  # Built-in Dependency Rules < Figure B-2 (Cont.) MMK default dependency rules -# AlphaHA _______________________________________________________O .RNH.HLP :. $(RUNOFF)$(RFLAGS) $(MMS$SOURCE) .RNO.MEM :. $(RUNOFF)$(RFLAGS) $(MMS$SOURCE) RUNOFF = RUNOFF_, RFLAGS = /OUTPUT=$(MMS$TARGET) .SCN$(OBJ) :/ $(SCAN)$(SCANFLAGS) $(MMS$SOURCE)  SCAN = SCANe? SCANFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)  CMS = CMS CMSCOMMENT = ""2 CMSFLAGS = /GENERATION=$(MMS$CMS_GEN) .B32~.B32 : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)_c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).B32 $(CMSFLAGS) $(CMSCOMMENT)  .BAS~.BAS : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)$c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).BAS $(CMSFLAGS) $(CMSCOMMENT)M .BLI~.BLI :MY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)$c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).BLI $(CMSFLAGS) $(CMSCOMMENT)M .C~.C :TY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ia $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).C $(CMSFLAGS) $(CMSCOMMENT)C .CLD~.CLD :PY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY) c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).CLD $(CMSFLAGS) $(CMSCOMMENT)(A _______________________________________________________T( Figure B-2 Cont'd on next page B-14 Y .A Built-in Dependency Rules < Figure B-2 (Cont.) MMK default dependency rules -# AlphaEA _______________________________________________________S .COB~.COB :Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Cc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COB $(CMSFLAGS) $(CMSCOMMENT)S .COR~.COR :Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Cc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COR $(CMSFLAGS) $(CMSCOMMENT)S .COM~.COM :Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Cc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COM $(CMSFLAGS) $(CMSCOMMENT)C .CXX~.CXX : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).CXX $(CMSFLAGS) $(CMSCOMMENT)_ .DAT~.DAT :_Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Dc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).DAT $(CMSFLAGS) $(CMSCOMMENT)E .DBL~.DBL :(Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Dc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).DBL $(CMSFLAGS) $(CMSCOMMENT)E .FOR~.FOR :(Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Dc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).FOR $(CMSFLAGS) $(CMSCOMMENT)E .H~.H :SY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ha $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).H $(CMSFLAGS) $(CMSCOMMENT)S .HLP~.HLP :AY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Nc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).HLP $(CMSFLAGS) $(CMSCOMMENT)R .MAC~.MAC :(Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Dc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MAC $(CMSFLAGS) $(CMSCOMMENT)EA _______________________________________________________ ( Figure B-2 Cont'd on next pageA B-15  M M# Built-in Dependency Rules < Figure B-2 (Cont.) MMK default dependency rules -# AlphaFA _______________________________________________________$ .MAR~.MAR :SY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Mc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MAR $(CMSFLAGS) $(CMSCOMMENT)$ .M64~.M64 :SY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Mc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).M64 $(CMSFLAGS) $(CMSCOMMENT)$ .MMS~.MMS :SY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)_c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MMS $(CMSFLAGS) $(CMSCOMMENT)  .MSG~.MSG : Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)tc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MSG $(CMSFLAGS) $(CMSCOMMENT)_ .OPT~.OPT :PY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ac $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).OPT $(CMSFLAGS) $(CMSCOMMENT)E .PAS~.PAS :AY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ac $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).PAS $(CMSFLAGS) $(CMSCOMMENT)E .PLI~.PLI :LY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ac $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).PLI $(CMSFLAGS) $(CMSCOMMENT)E .R32~.R32 :3Y @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ac $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).R32 $(CMSFLAGS) $(CMSCOMMENT)E .REQ~.REQ :EY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ac $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).REQ $(CMSFLAGS) $(CMSCOMMENT)E .RNH~.RNH :NY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Ac $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNH $(CMSFLAGS) $(CMSCOMMENT)EA _______________________________________________________.( Figure B-2 Cont'd on next page B-16  CA Built-in Dependency Rules < Figure B-2 (Cont.) MMK default dependency rules -# AlphaSA _______________________________________________________) .RNO~.RNO :EY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Bc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNO $(CMSFLAGS) $(CMSCOMMENT)N .SCN~.SCN :AY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)Bc $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).SCN $(CMSFLAGS) $(CMSCOMMENT)N .SDML~.SDML :EY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)_d $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).SDML $(CMSFLAGS) $(CMSCOMMENT) .TXT~.TXT :lY @ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)-c $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).TXT $(CMSFLAGS) $(CMSCOMMENT)_A _______________________________________________________eA B-17   MA _______________________________________________________A% C Using the CROSS_ALPHA Rules = The CROSS_ALPHA.MMS rules file is included with MMKV? as an aid to developers working on programs that will ; be run on both VAX and Alpha systems. The defaultd: dependency rules built into MMK are based on the< macros show in Table C-1. They are used by default( on both VAX and Alpha systems.A Table_C-1__MMK_default_suffix_macros___________________LA Macro______Suffix____Meaning___________________________2/ $(EXE) .EXE Executable image 1 $(L32) .L32 BLISS Library fileo* $(OBJ) .OBJ Object file- $(OLB) .OLB Object libraryNA $(OPT)_____.OPT______Linker_options_file_______________9 Since the files mentioned in the table are of a_? different format on OpenVMS Alpha systems, developers= wishing to do both Alpha and VAX builds in the same @ directory need a way of preventing the differing files? from interfering with each other. The CROSS_ALPHA.MMS-: rules redefine the macros as shown in Table C-2,( eliminating the name conflict.A Table_C-2__CROSS_ALPHA_suffix_macros___________________iA Macro______Suffix____Meaning___________________________e/ $(EXE) .ALPHA_ Executable image_ EXEA C-1s y l% Using the CROSS_ALPHA RulesuA Table_C-2_(Cont.)__CROSS_ALPHA_suffix_macros___________ A Macro______Suffix____Meaning___________________________ 1 $(L32) .L32E BLISS Library file * $(OBJ) .ALPHA_ Object file OBJ- $(OLB) .ALPHA_ Object library. OLB2 $(OPT) .ALPHA_ Linker options fileA ___________OPT_________________________________________ @ To make all this work, you must use the macros in your? description file instead of making literal referencesO1 to the file type suffixes. For example:LX PROGRAM$(EXE) : PROGRAM$(OBJ),SUBROUTINES$(OBJ),PROGRAM$(OPT)G $(LINK)$(LINKFLAGS) PROGRAM$(OPT)/OPTION 4 PROGRAM$(OBJ) : PROGRAM.C> SUBROUTINES$(OBJ) : SUBROUTINES.FOR= It also helps to use the macros for the commands to$@ compile and link programs, especially if you are using> DEC's Alpha Migration Tools and cross-compiling your AXP objects on a VAX. 9 In addition to using the CROSS_ALPHA rules, MMKu= provides the special macros __AXP__ and __ALPHA__, = which are predefined only when MMK is running on anl: OpenVMS AXP system (it also provides the __VAX__= predefined macro for VAX-based builds). This allowsC> you to conditionalize your description file with the; .IFDEF directive to handle Alpha- or VAX-specificR cases. C-2