Guide to MadGoat Make Utility
February, 1997
This manual describes the MadGoat Make Utility (MMK),
a "make" utility for VMS systems.
Revision/Update Information: This is a revised manual.
Operating System and Version: VAX/VMS V5.2 or later;
OpenVMS AXP V1.5 or later
Software Version: MMK V3.6
Matthew Madison
MadGoat Software
________________________
15 February 1997
Permission is granted to copy and redistribute this
document for no commercial gain.
The information in this document is subject to change
without notice and should not be construed as a
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:
AXP DEC OpenVMS
VAX VMS
UNIX is a registered trademark of USL, Inc.
__________
Copyright ©1993, 1994, 1995, 1996, 1997 MadGoat
Software. All Rights Reserved.
_______________________________________________________
Contents
_________________________________________________
PREFACE vii
_______________________________________________________
CHAPTER 1 INTRODUCTION 1-1
_________________________________________________
1.1 OVERVIEW 1-1
_________________________________________________
1.2 INVOKING MMK 1-2
_______________________________________________________
CHAPTER 2 DESCRIPTION FILES 2-1
_________________________________________________
2.1 DESCRIPTION FILE COMPONENTS 2-1
_________________________________________________
2.2 USING INFERENCE RULES 2-2
_________________________________________________
2.3 DEFINING INFERENCE RULES 2-3
_________________________________________________
2.4 FORCED SETUP/TEARDOWN ACTIONS IN
INFERENCE RULES 2-5
_________________________________________________
2.5 MODIFYING THE SUFFIX LIST 2-5
_________________________________________________
2.6 USING CONDITIONALS 2-6
iii
Contents
_________________________________________________
2.7 DEFERRING MACRO SUBSTITUTION 2-7
_______________________________________________________
CHAPTER 3 USING DEC/CMS WITH MMK 3-1
_________________________________________________
3.1 THE /CMS QUALIFIER 3-1
_________________________________________________
3.2 EXPLICIT CMS ELEMENT REFERENCES 3-1
3.2.1 Specifying the Element
Generation ____________________ 3-2
_________________________________________________
3.3 INFERENCE RULES FOR CMS FILES 3-2
3.3.1 CMS and Prefixed Inference
Rules _________________________ 3-3
MMK 3-4
_______________________________________________________
APPENDIX A DIFFERENCES BETWEEN MMK AND DEC/MMS A-1
_________________________________________________
A.1 DEC/MMS FEATURES NOT SUPPORTED IN
MMK A-1
_________________________________________________
A.2 MMK EXTENDED FEATURES A-2
_________________________________________________
A.3 OTHER DIFFERENCES A-4
iv
Contents
_______________________________________________________
APPENDIX B BUILT-IN DEPENDENCY RULES B-1
_______________________________________________________
APPENDIX C USING THE CROSS_ALPHA RULES C-1
_______________________________________________________
FIGURES
B-1 MMK default dependency rules -
VAX ___________________________ B-1
B-2 MMK default dependency rules -
AXP ___________________________ B-9
_______________________________________________________
TABLES
C-1 MMK default suffix macros _____ C-1
C-2 CROSS_ALPHA suffix macros _____ C-1
v
_______________________________________________________
Preface
This guide explains how to install and use the MadGoat
Make Utility (MMK).
__________________________________________________________________
Intended Audience
This manual is intended for all MMK users, primarily
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.
Note: This is a DRAFT document, and is still under
construction. New users are advised to learn more
about description files (makefiles) by reviewing
either DEC/MMS documentation or books on the UNIX make
utility.
__________________________________________________________________
Document Structure
tbs
__________________________________________________________________
Related Documents
tbs
__________________________________________________________________
Conventions
In this document, the following convention will be
used for the names of the three similar utilities:
o MMK refers to MadGoat Make, the package described in
this document.
o DEC/MMS refers to VAX DEC/Module Management System,
a product of Digital Equipment Corporation.
vii
Preface
o make refers to the UNIX make utility.
viii
_______________________________________________________
1 Introduction
This chapter describes MadGoat Make (MMK). It includes
an overview of MMK and basic information on its use.
__________________________________________________________________
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:
1 MMK reads and parses the description file,
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 is
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.
1-1
Introduction
In this way, MMK can execute the commands to rebuild
only those pieces of your software system that need
rebuilding due to a change that you have made.
This can drastically reduce development time for a
project.
__________________________________________________________________
1.2 Invoking MMK
Provided that MMK has been installed using the steps
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.
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
_______________________________________________________
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 format
for a description file and its components.
__________________________________________________________________
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 based
on suffixes (and possibly directories as well), from
which MMK can infer dependencies and actions without
you having to list them explicitly in your makefile.
o MMK directives, which provide a means for adding
commands to be executed before or after all
other actions, provide a simple conditional-build
mechanism, and other directives for modifying MMK's
behavior.
2-1
Description Files
Here is an example of a simple description file:
PROGRAM.EXE : MAIN.OBJ,SUBROUTINES.OBJ
LINK/EXEC=PROGRAM.EXE MAIN.OBJ,SUBROUTINES.OBJ
MAIN.OBJ : MAIN.FOR
FORTRAN MAIN
SUBROUTINES.OBJ : SUBROUTINES.MAR
MACRO SUBROUTINES
This is a simple collection of dependencies and
actions for building an image called PROGRAM.EXE.
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.
__________________________________________________________________
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 types
in order to make use of the default rules.
For example, the description file in the last section
could be simplified to just:
PROGRAM.EXE : MAIN.OBJ,SUBROUTINES.OBJ
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
Description Files
The description file could even be simplified further,
to just:
PROGRAM.EXE : MAIN.OBJ,SUBROUTINES.OBJ
LINK/EXEC=PROGRAM.EXE MAIN.OBJ,SUBROUTINES.OBJ
MMK automatically searches the suffixes list when
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 a
combination of source and target suffixes. This second
purpose can greatly simplify your makefiles, and makes
the build process more automatic.
__________________________________________________________________
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 through
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 :
CC/OBJECT=$(MMS$TARGET) $(MMS$SOURCE)
which says, "to build filename.OBJ from an existing
file called filename.C, use the CC command." In
general, generic rules work best when the source and
target files reside in the same directory.
2-3
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 prefixed
rule:
{SRC$:}.C{OBJ$:}.OBJ :
CC/OBJECT=$(MMS$TARGET) $(MMS$SOURCE)
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.
You can have more than one prefixed rule for a
particular pair of suffixes; you may also mix generic
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 "}") are
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
as it exists in the description file must match
the prefix in the rule; MMK performs no logical
name translation on prefixes, nor can it identify
equivalencies between two prefixes that reference the
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 has
a built-in generic rule for .C.OBJ, which is:
2-4
Description Files
.C.OBJ :
$(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.
__________________________________________________________________
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 any
unmodified action. The teardown modifier, ">", forces
the execution of an action after all other actions.
Setup and teardown actions are performed for all
dependencies matching the inference rule, even if a
dependency includes explicit actions.
For example, the inference rule
.C.OBJ :
< 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.C
$(CC)$(CFLAGS)/DEFINE=FRED $(MMS$SOURCE)
__________________________________________________________________
2.5 Modifying the Suffix List
MMK uses a suffix list to determine the inference
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.
2-5
Description Files
You can augment or replace the built-in suffix
list with your own suffixes by using the .SUFFIXES
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
(suffix) of .MOD. MMK has no built-in inference
rules for this file type; you could add one with the
following sequence:
.SUFFIXES : .MOD
.MOD.OBJ :
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 a
Modula-2 source file.
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 with
another .SUFFIXES directive that specifies only those
suffixes for which you want inference rules to be
enabled.
__________________________________________________________________
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, .ELSE, and .ENDIF. The
.IFDEF, .ELSE, and .ENDIF directives work the same as
for MMS; the .IF directive is an MMK extension. Its
syntax is
.IF "expression1" comparison "expression2"
where expression1 and expression2 can be any string
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.
2-6
Description Files
The comparison operator is either EQL (equals) or
NEQ (not equals). The quotation marks around the two
expressions are required. Comparisons are performed
without regard to upper/lower case.
__________________________________________________________________
2.7 Deferring Macro Substitution
MMK provides a way to defer the resolution of a
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's
"special" macros, such as MMS$SOURCE and MMS$TARGET).
You can defer this substitution in MMK by using the
syntax ${name} instead. However, this syntax is
only recognized on the right-hand side of a macro
definition. This can be useful when defining macros
in a rules file that rely on macros that do not get
defined until another rules file or a description
file gets processed. For example, you might have the
following definition in a rules file:
CFLAGS = /OBJECT=$(MMS$TARGET)/NOLIST/DEFINE=(VMS_BUILD,${MOREDEFINES})
then in your description file, you can define the
MOREDEFINES macro:
MOREDEFINES = ANOTHER_C_DEFINE
This will complete the CFLAGS macro value when it is
referenced later in the description file.
2-7
_______________________________________________________
3 Using DEC/CMS with MMK
This chapter describes the use of Digital's DEC/Code
Management System (DEC/CMS) with MMK.
__________________________________________________________________
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 that
you specify, for the current build. This causes
source files to be fetched out of the DEC/CMS library
automatically, if needed. In addition, the MMK
description file will automatically be fetched out
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 files
out of DEC/CMS libraries. Suffixes ending in a tilde
character ("~") signify DEC/CMS library elements. The
built-in DEC/CMS element rules are used only if /CMS
is specified on the MMK command.
__________________________________________________________________
3.2 Explicit CMS Element References
You can explicitly reference a CMS library element in
your MMK description file by adding a tilde to the end
of the file specification. For example:
MAIN.FOR : MAIN.FOR~
You can also explicitly name the CMS library from
which the element should be fetched, by specifying a
device and/or directory name:
MAIN.FOR : SOURCE_DISK:[CMS_SOURCE]MAIN.FOR~
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.
___________________________
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 whichever
generation you specify on the MMK /GENERATION
qualifier. If you need to build a dependency on a
specific generation of an element, you may do so by
specifying the /GENERATION qualifier on the file name:
MAIN.FOR : MAIN.FOR~/GENERATION=37
The above example would cause generation 37 of the
MAIN.FOR file in the current CMS library to be used
for the build.
__________________________________________________________________
3.3 Inference Rules for CMS Files
MMK comes with built-in inference rules for fetching
source files from a CMS library. Like DEC/MMS, MMK
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 library
and will fetch it out of the library if needed.
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
Using DEC/CMS with MMK
___________________________
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-
platform development project which used two CMS
libraries - one for OS-specific source code and
another for common source code - you might use the
following prefixed rules:
{CMSSRC:[VMS_SPECIFIC]}.FOR~{}.FOR :
{CMSSRC:[COMMON]}.FOR~{}.FOR :
This sequence would cause MMK to automatically search
the CMSSRC:[VMS_SPECIFIC] CMS library for a FORTRAN
source file, then search the CMSSRC:[COMMON] library.
If the file were not located in either library,
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.
3-3
MMK
_______________________________________________________
MMK
Invokes the MMK utility to build a software system.
_______________________________________________________
FORMAT
MMK [target-name ...]
_______________________________________________________
Command Qualifiers Defaults
/[NO]ACTION /ACTION
/[NO]CHECK_STATUS /NOCHECK_STATUS
/[NO]CMS /NOCMS
/CMS_LIBRARY=dir-spec
/DESCRIPTION=file-spec
/DUMP
/[NO]FORCE /NOFORCE
/[NO]FROM_SOURCES /NOFROM_SOURCES
/GENERATION=string /GENERATION="1+"
/IDENTIFICATION
/[NO]IGNORE[=level] /NOIGNORE
/[NO]LOCAL_RULES /LOCAL_RULES
/[NO]LOG /NOLOG
/MACRO=file-spec | definition...
/OUTPUT=file-spec
/[NO]OVERRIDE /NOOVERRIDE
/[NO]RULES_FILE=file-spec...
/[NO]SKIP_INTERMEDIATE/NOSKIP_INTERMEDIATES
/[NO]VERIFY /VERIFY
_______________________________________________________
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
MMK
in the description file. Multiple targets may be
specified as a comma-separated list.
_______________________________________________________
DESCRIPTION
The MMK utility builds a software system from the
objects and dependencies listed in a description file.
See the documentation for additional information.
_______________________________________________________
QUALIFIERS
/[NO]ACTION
Determines whether action lines are executed or just
displayed. Specifying /NOACTION causes MMK to display
the action lines that would be executed to build the
target, without actually executing them.
/[NO]CHECK_STATUS
Directs MMK to determine whether a target is up-to-
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.
This qualifier overrides the /ACTION qualifier.
/[NO]CMS
Determines whether a DEC/Code Management System
(CMS) library is automatically searched for the MMK
description file and for any source files. The default
is /NOCMS, which omits any CMS checks.
/CMS_LIBRARY=dir-spec
Specifies a DEC/Code Management System (CMS) library
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 is
also specified. If omitted, the default CMS library
(from the logical name CMS$LIB or the CMS SET LIBRARY
command) is used.
3-5
MMK
/DESCRIPTION=file-spec
Specifies an alternative name for the MMK description
file. The default description file name is DESCRIP.MMS
(in the current default directory), with MAKEFILE.
being used if DESCRIP.MMS does not exist.
/DUMP
Causes MMK to dump the suffix list, all currently
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.
/[NO]FORCE
Specifying /FORCE causes MMK to execute only the
action lines from the dependency rule for the target,
without performing any revision date checks and
without building any intermediate targets.
/[NO]FROM_SOURCES
Specifying /FROM_SOURCES causes MMK to perform a
complete build of the target, ignoring revision dates.
All actions to build all intermediate targets are
executed.
/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.
/IDENTIFICATION
Specifying /IDENTIFICATION causes MMK to display its
revision information and a copyright message, without
performing any other action.
3-6
MMK
/[NO]IGNORE[=level]
By default, MMK stops when an executed action line
results in a warning, error, or fatal error status.
You can override this by specifying /IGNORE. Using
/IGNORE or /IGNORE=FATAL causes all errors to be
ignored; specifying /IGNORE=ERROR causes errors and
warnings to be ignored; specifying /IGNORE=WARNING
causes only warnings to be ignored.
/[NO]LOCAL_RULES
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
its activity. By default, it does not.
/MACRO=file-spec | definintion...
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 file
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 be
found, the name is treated as macro definition, and a
value of 1 is assigned to the macro by default.
If an equals sign is present, the macro definition is
taken directly from the command line.
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
Directs MMK output to a location other than the
default, SYS$OUTPUT.
3-7
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 by
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...]
Specifies the name of one or more description
files containing inference rules. If /RULES_FILE
is specified with no file specification, the name
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.
/[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_
INTERMEDIATES causes MMK to treat these missing
sources as if they exist and have the same revision
date/time stamp as the target that depends on them.
3-8
MMK
For example, if the target is a .EXE file which
depends on a .OBJ file, and that .OBJ file in turn
depends on a .C file, by default MMK will build the
.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
Controls whether MMK echoes action lines to
SYS$OUTPUT. Enabled by default.
3-9
_______________________________________________________
A Differences between MMK and DEC/MMS
MMK is patterned after DEC/MMS, but contains only a
subset of DEC/MMS functionality and differs somewhat
in its operation. This appendix lists some of the
differences between MMK and DEC/MMS.
Besides the differences in features, there are some
differences in processing between MMK and DEC/MMS
which may lead to different results or syntax errors
in MMK for description files which operate properly
under DEC/MMS. If possible, please report any such
differences to the author so that they can be fixed.
__________________________________________________________________
A.1 DEC/MMS Features Not Supported in MMK
MMK does not support the following DEC/MMS features:
o MMK does not support FMS forms libraries.
o MMK does not honor the "; action" syntax on
dependency rule lines can be used with DEC/MMS.
Make sure all actions are on separate lines.
o MMK requires the leading dot on the .INCLUDE
directive.
o MMK does not handle wildcard dependency rules.
o MMK does not support all of the command qualifiers
supported by DEC/MMS. In addition, the MMK's
/GENERATION qualifier is completely different from
DEC/MMS's /GENERATE qualifier.
o MMK does not have a DECwindows interface.
A-1
Differences between MMK and DEC/MMS
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_
LOCAL_RULES or MMK_PERSONAL_RULES logical names to
have rules automatically loaded by MMK.
__________________________________________________________________
A.2 MMK Extended Features
MMK includes the following features not found in
DEC/MMS:
o MMK gives you more options for rules file, and is
set up to allow multiple rules files to be present.
Rule file processing follows this sequence:
1 The default rules compiled into MMK are loaded
automatically unless /NORULES_FILE is specified
on the MMK command.
2 A site-defined local rules file is loaded
automatically if the logical name MMK_LOCAL_RULES
is defined (use /NOLOCAL_RULES to override).
3 If the /RULES_FILE qualifier is specified, any
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 the
logical name MMS$RULES).
If the /RULES_FILE qualifier is omitted, a
personal rules file is loaded if the logical
name MMK_PERSONAL_RULES is defined. MMS$RULES is
not loaded in this case.
If /NORULES_FILE is specified, neither MMS$RULES
nor the personal rules file is loaded.
These rules-processing features, coupled with the
ability to redefine macros defined in rules files,
make it easier to customize MMK's behavior when
needed.
A-2
Differences between MMK and DEC/MMS
o MMK trims blanks out of $(MMS$SOURCE_LIST).
o MMK includes support for the following special local
macros:
o $(MMS$SOURCE_LIST_SPACES) - source list with
spaces as separators instead of commas.
o $(MMS$CHANGED_LIST_SPACES) - list of changed
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),
but does not include the device/directory
specification, just the filename.
o $(MMS$TARGET_MODULE) - name of the module being
replaced in a text, help, macro, or object
library.
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.
o MMK, in most cases, has more flexible syntax rules
for its description files, allowing blanks where MMS
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 AXP 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 that
file currently resides in a CMS library.
o MMK includes a /DUMP qualifier for debugging
problems with makefiles.
A-3
Differences between MMK and DEC/MMS
o MMK provides a /GENERATION qualifier on the MMK
command for specifying the default CMS generation to
be used when elements are checked for revisions and
fetched out of CMS.
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.
o MMK adds the ${name} syntax for deferring resolution
of macros on the right-hand side of a macro
definition.
o MMK adds the .IF directive to make it easier to
conditionalize builds.
You may want to avoid using these extended features if
you need to maintain compatibility with DEC/MMS.
__________________________________________________________________
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, to
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 messages
in certain cases.
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,
although if the description file is correct, the end
result will be the same.
A-4
Differences between MMK and DEC/MMS
o MMK parses comments and continuation lines
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-5
_______________________________________________________
B Built-in Dependency Rules
The dependency rules built into MMK for VAX systems is
given in Figure B-1. The dependency rules built into
MMK for AXP systems is given in Figure B-2.
Figure B-1 MMK default dependency rules - VAX
_______________________________________________________
! MMK_DEFAULT_RULES.MMS
!
! COPYRIGHT © 1993, 1994, 1997 MADGOAT SOFTWARE. ALL RIGHTS RESERVED.
!
! Default build rules for use with MMK. (for VAX systems)
!
! Modification history:
!
! 23-DEC-1992 V1.0 Madison Initial coding.
! 17-OCT-1993 V1.1 Madison Elimination of intermediate libfiles.
! 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.
! 22-AUG-1994 V2.1-1 Madison Eliminate DELETE_SOURCE checks.
! 14-OCT-1994 V2.2 Madison Add CXX support.
! 28-DEC-1994 V2.3 Madison Make IF commands silent.
! 20-JUN-1997 V2.3-1 Madison Add .MAR.MLB inference rule.
!
_______________________________________________________
Figure B-1 Cont'd on next page
B-1
Built-in Dependency Rules
Figure B-1 (Cont.) MMK default dependency rules - VAX
_______________________________________________________
!
! These symbols can be used to distinguish MMK from DEC's DEC/MMS product
! using .IFDEF directives.
!
__MATTS_MMS__ = __MATTS_MMS__
__MMK__ = __MMK__
__MMK_V32__ = 1
!
! This symbol can be used to distinguish a VAX-based build from an
! AXP-based build. (or use .IFDEF __AXP__ .ELSE ... .ENDIF)
!
__VAX__ = 1
EXE = .EXE
OLB = .OLB
OBJ = .OBJ
OPT = .OPT
L32 = .L32
.SUFFIXES : ! clear the suffix list first
.SUFFIXES : $(EXE) $(OLB) $(OBJ) .TLB .HLB .MLB $(L32) .C .CXX .BAS .B32 .BLI .FOR -
.COB .COR .DBL .RPG .SCN .PLI .PEN .PAS .MAC .MAR .MSG .CLD .R32 -
.REQ .TXT .H .MEM .HLP .RNH .RNO .MMS .DAT .OPT .SDML .COM -
.C~ .CXX~ .BAS~ .B32~ .BLI~ .FOR~ .COB~ .COR~ .DBL~ .RPG~ .SCN~ -
.PLI~ .PAS~ .MAC~ .MAR~ .MSG~ .CLD~ .R32~ .REQ~ .TXT~ -
.H~ .HLP~ .RNH~ .RNO~ .MMS~ .DAT~ .OPT~ .SDML~ .COM~
LINK = LINK
LINKFLAGS = /EXEC=$(MMS$TARGET)
$(OBJ)$(OLB) :
@ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE $(MMS$TARGET)
$(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
.TXT.TLB :
@ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/TEXT $(MMS$TARGET)
$(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)/MODULE=$(MMS$TARGET_MODULE)
_______________________________________________________
Figure B-1 Cont'd on next page
B-2
Built-in Dependency Rules
Figure B-1 (Cont.) MMK default dependency rules - VAX
_______________________________________________________
.HLP.HLB :
@ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/HELP $(MMS$TARGET)
$(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
.MAC.MLB :
@ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/MACRO $(MMS$TARGET)
$(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
.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 = BASIC
BASFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.BLI$(OBJ) :
$(BLISS)$(BFLAGS) $(MMS$SOURCE)
.B32$(OBJ) :
$(BLISS)$(BFLAGS) $(MMS$SOURCE)
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)
COBOL = COBOL
COBFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
_______________________________________________________
Figure B-1 Cont'd on next page
B-3
Built-in Dependency Rules
Figure B-1 (Cont.) MMK default dependency rules - VAX
_______________________________________________________
.COR$(OBJ) :
$(CORAL)$(CORFLAGS) $(MMS$SOURCE)
CORAL = CORAL
CORFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.CXX$(OBJ) :
$(CXX)$(CXXFLAGS) $(MMS$SOURCE)
CXX = CXX
CXXFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.DBL$(OBJ) :
$(DIBOL)$(DBLFLAGS) $(MMS$SOURCE)
DIBOL = DIBOL
DBLFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.CLD$(OBJ) :
$(SETCMD)$(SETCMDFLAGS) $(MMS$SOURCE)
SETCMD = SET COMMAND
SETCMDFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.FOR$(OBJ) :
$(FORT)$(FFLAGS) $(MMS$SOURCE)
FORT = FORTRAN
FFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.MAR$(OBJ) :
$(MACRO)$(MFLAGS) $(MMS$SOURCE)
MACRO = MACRO
MFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.MSG$(OBJ) :
$(MESSAGE)$(MSGFLAGS) $(MMS$SOURCE)
MESSAGE = MESSAGE
MSGFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
_______________________________________________________
Figure B-1 Cont'd on next page
B-4
Built-in Dependency Rules
Figure B-1 (Cont.) MMK default dependency rules - VAX
_______________________________________________________
.PAS$(OBJ) :
$(PASCAL)$(PFLAGS) $(MMS$SOURCE)
.PAS.PEN :
$(PASCAL)$(PENVFLAGS) $(MMS$SOURCE)
PASCAL = PASCAL
PFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
PENVFLAGS = /ENVIRONMENT=$(MMS$TARGET_NAME).PEN/NOLIST
.PLI$(OBJ) :
$(PLI)$(PLIFLAGS) $(MMS$SOURCE)
PLI = PLI
PLIFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.REQ$(L32) :
$(BLISS)/LIBR=$(MMS$TARGET_NAME)$(L32)$(BLIBFLAGS) $(MMS$SOURCE)
.R32$(L32) :
$(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 = RUNOFF
RFLAGS = /OUTPUT=$(MMS$TARGET)
_______________________________________________________
Figure B-1 Cont'd on next page
B-5
Built-in Dependency Rules
Figure B-1 (Cont.) MMK default dependency rules - VAX
_______________________________________________________
.SCN$(OBJ) :
$(SCAN)$(SCANFLAGS) $(MMS$SOURCE)
SCAN = SCAN
SCANFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
CMS = CMS
CMSCOMMENT = ""
CMSFLAGS = /GENERATION=$(MMS$CMS_GEN)
.B32~.B32 :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).B32 $(CMSFLAGS) $(CMSCOMMENT)
.BAS~.BAS :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).BAS $(CMSFLAGS) $(CMSCOMMENT)
.BLI~.BLI :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).BLI $(CMSFLAGS) $(CMSCOMMENT)
.C~.C :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).C $(CMSFLAGS) $(CMSCOMMENT)
.CLD~.CLD :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).CLD $(CMSFLAGS) $(CMSCOMMENT)
.COB~.COB :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COB $(CMSFLAGS) $(CMSCOMMENT)
.COR~.COR :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COR $(CMSFLAGS) $(CMSCOMMENT)
.COM~.COM :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COM $(CMSFLAGS) $(CMSCOMMENT)
_______________________________________________________
Figure B-1 Cont'd on next page
B-6
Built-in Dependency Rules
Figure B-1 (Cont.) MMK default dependency rules - VAX
_______________________________________________________
.CXX~.CXX :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).CXX $(CMSFLAGS) $(CMSCOMMENT)
.DAT~.DAT :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).DAT $(CMSFLAGS) $(CMSCOMMENT)
.DBL~.DBL :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).DBL $(CMSFLAGS) $(CMSCOMMENT)
.FOR~.FOR :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).FOR $(CMSFLAGS) $(CMSCOMMENT)
.H~.H :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).H $(CMSFLAGS) $(CMSCOMMENT)
.HLP~.HLP :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).HLP $(CMSFLAGS) $(CMSCOMMENT)
.MAC~.MAC :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MAC $(CMSFLAGS) $(CMSCOMMENT)
.MAR~.MAR :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MAR $(CMSFLAGS) $(CMSCOMMENT)
.MMS~.MMS :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MMS $(CMSFLAGS) $(CMSCOMMENT)
.MSG~.MSG :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MSG $(CMSFLAGS) $(CMSCOMMENT)
_______________________________________________________
Figure B-1 Cont'd on next page
B-7
Built-in Dependency Rules
Figure B-1 (Cont.) MMK default dependency rules - VAX
_______________________________________________________
.OPT~.OPT :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).OPT $(CMSFLAGS) $(CMSCOMMENT)
.PAS~.PAS :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).PAS $(CMSFLAGS) $(CMSCOMMENT)
.PLI~.PLI :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).PLI $(CMSFLAGS) $(CMSCOMMENT)
.R32~.R32 :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).R32 $(CMSFLAGS) $(CMSCOMMENT)
.REQ~.REQ :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).REQ $(CMSFLAGS) $(CMSCOMMENT)
.RNH~.RNH :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNH $(CMSFLAGS) $(CMSCOMMENT)
.RNO~.RNO :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNO $(CMSFLAGS) $(CMSCOMMENT)
.SCN~.SCN :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).SCN $(CMSFLAGS) $(CMSCOMMENT)
.SDML~.SDML :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).SDML $(CMSFLAGS) $(CMSCOMMENT)
.TXT~.TXT :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).TXT $(CMSFLAGS) $(CMSCOMMENT)
_______________________________________________________
Figure B-1 Cont'd on next page
B-8
Built-in Dependency Rules
Figure B-1 (Cont.) MMK default dependency rules - VAX
_______________________________________________________
_______________________________________________________
Figure B-2 MMK default dependency rules - AXP
_______________________________________________________
! MMK_DEFAULT_RULES_AXP.MMS
!
! COPYRIGHT © 1993, 1997 MADGOAT SOFTWARE. ALL RIGHTS RESERVED.
!
! Default build rules for use with MMK. (for OpenVMS AXP)
!
! Modification history:
!
! 23-DEC-1992 V1.0 Madison Initial coding.
! 17-OCT-1993 V1.1 Madison Delete intermediate libfiles.
! 11-APR-1994 V1.2 Madison Make rules more like MMS's.
! 05-JUL-1994 V2.0 Madison Add CMS support.
! 16-JUL-1994 V2.1 Madison Update for V3.2.
! 22-AUG-1994 V2.1-1 Madison Eliminate DELETE_SOURCE checks.
! 14-OCT-1994 V2.2 Madison Add CXX support.
! 28-DEC-1994 V2.3 Madison Make IF commands silent.
! 20-JUN-1997 V2.3-1 Madison Add .MAR.MLB inference rule.
!
_______________________________________________________
Figure B-2 Cont'd on next page
B-9
Built-in Dependency Rules
Figure B-2 (Cont.) MMK default dependency rules - AXP
_______________________________________________________
!
! This symbol can be used to distinguish MMK from DEC's DEC/MMS product
! using .IFDEF directives.
!
__MATTS_MMS__ = __MATTS_MMS__
__MMK__ = __MMK__
__MMK_V32__ = 1
!
! These symbols can be used to distinguish an AXP-based build from a
! VAX-based build.
!
__ALPHA__ = 1
__AXP__ = 1
EXE = .EXE
OLB = .OLB
OBJ = .OBJ
OPT = .OPT
L32 = .L32
.SUFFIXES : ! clear the suffix list first
.SUFFIXES : $(EXE) $(OLB) $(OBJ) .TLB .HLB .MLB $(L32) .C .CXX .BAS .B32 .BLI .FOR -
.COB .COR .DBL .RPG .SCN .PLI .PEN .PAS .MAC .MAR .M64 .MSG .CLD -
.R32 .REQ .TXT .H .MEM .HLP .RNH .RNO .MMS .DAT .OPT .SDML .COM -
.C~ .CXX~ .BAS~ .B32~ .BLI~ .FOR~ .COB~ .COR~ .DBL~ .RPG~ .SCN~ -
.PLI~ .PAS~ .MAC~ .MAR~ .M64~ .MSG~ .CLD~ .R32~ .REQ~ .TXT~ -
.H~ .HLP~ .RNH~ .RNO~ .MMS~ .DAT~ .OPT~ .SDML~ .COM~
LINK = LINK
LINKFLAGS = /EXEC=$(MMS$TARGET)
$(OBJ)$(OLB) :
@ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE $(MMS$TARGET)
$(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
.TXT.TLB :
@ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/TEXT $(MMS$TARGET)
$(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)/MODULE=$(MMS$TARGET_MODULE)
_______________________________________________________
Figure B-2 Cont'd on next page
B-10
Built-in Dependency Rules
Figure B-2 (Cont.) MMK default dependency rules - AXP
_______________________________________________________
.HLP.HLB :
@ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/HELP $(MMS$TARGET)
$(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
.MAC.MLB :
@ IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/MACRO $(MMS$TARGET)
$(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
.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 = BASIC
BASFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.BLI$(OBJ) :
$(BLISS)$(BFLAGS) $(MMS$SOURCE)
.B32$(OBJ) :
$(BLISS)$(BFLAGS) $(MMS$SOURCE)
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)
COBOL = COBOL
COBFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
_______________________________________________________
Figure B-2 Cont'd on next page
B-11
Built-in Dependency Rules
Figure B-2 (Cont.) MMK default dependency rules - AXP
_______________________________________________________
.COR$(OBJ) :
$(CORAL)$(CORFLAGS) $(MMS$SOURCE)
CORAL = CORAL
CORFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.CXX$(OBJ) :
$(CXX)$(CXXFLAGS) $(MMS$SOURCE)
CXX = CXX
CXXFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.DBL$(OBJ) :
$(DIBOL)$(DBLFLAGS) $(MMS$SOURCE)
DIBOL = DIBOL
DBLFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.CLD$(OBJ) :
$(SETCMD)$(SETCMDFLAGS) $(MMS$SOURCE)
SETCMD = SET COMMAND
SETCMDFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.FOR$(OBJ) :
$(FORT)$(FFLAGS) $(MMS$SOURCE)
FORT = FORTRAN
FFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.MAR$(OBJ) :
$(MACRO)$(MFLAGS) $(MMS$SOURCE)
MACRO = MACRO/MIGRATION
MFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.M64$(OBJ) :
$(TASM)$(TASMFLAGS) $(MMS$SOURCE)
TASM = MACRO
TASMFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
_______________________________________________________
Figure B-2 Cont'd on next page
B-12
Built-in Dependency Rules
Figure B-2 (Cont.) MMK default dependency rules - AXP
_______________________________________________________
.MSG$(OBJ) :
$(MESSAGE)$(MSGFLAGS) $(MMS$SOURCE)
MESSAGE = MESSAGE
MSGFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.PAS$(OBJ) :
$(PASCAL)$(PFLAGS) $(MMS$SOURCE)
.PAS.PEN :
$(PASCAL)$(PENVFLAGS) $(MMS$SOURCE)
PASCAL = PASCAL
PFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
PENVFLAGS = /ENVIRONMENT=$(MMS$TARGET_NAME).ENV/NOLIST
.PLI$(OBJ) :
$(PLI)$(PLIFLAGS) $(MMS$SOURCE)
PLI = PLI
PLIFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
.REQ$(L32) :
$(BLISS)/LIBR=$(MMS$TARGET_NAME)$(L32)$(BLIBFLAGS) $(MMS$SOURCE)
.R32$(L32) :
$(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)
_______________________________________________________
Figure B-2 Cont'd on next page
B-13
Built-in Dependency Rules
Figure B-2 (Cont.) MMK default dependency rules - AXP
_______________________________________________________
.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 = SCAN
SCANFLAGS = /NOLIST/OBJECT=$(MMS$TARGET_NAME)$(OBJ)
CMS = CMS
CMSCOMMENT = ""
CMSFLAGS = /GENERATION=$(MMS$CMS_GEN)
.B32~.B32 :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).B32 $(CMSFLAGS) $(CMSCOMMENT)
.BAS~.BAS :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).BAS $(CMSFLAGS) $(CMSCOMMENT)
.BLI~.BLI :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).BLI $(CMSFLAGS) $(CMSCOMMENT)
.C~.C :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).C $(CMSFLAGS) $(CMSCOMMENT)
.CLD~.CLD :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).CLD $(CMSFLAGS) $(CMSCOMMENT)
.COB~.COB :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COB $(CMSFLAGS) $(CMSCOMMENT)
_______________________________________________________
Figure B-2 Cont'd on next page
B-14
Built-in Dependency Rules
Figure B-2 (Cont.) MMK default dependency rules - AXP
_______________________________________________________
.COR~.COR :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COR $(CMSFLAGS) $(CMSCOMMENT)
.COM~.COM :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).COM $(CMSFLAGS) $(CMSCOMMENT)
.CXX~.CXX :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).CXX $(CMSFLAGS) $(CMSCOMMENT)
.DAT~.DAT :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).DAT $(CMSFLAGS) $(CMSCOMMENT)
.DBL~.DBL :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).DBL $(CMSFLAGS) $(CMSCOMMENT)
.FOR~.FOR :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).FOR $(CMSFLAGS) $(CMSCOMMENT)
.H~.H :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).H $(CMSFLAGS) $(CMSCOMMENT)
.HLP~.HLP :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).HLP $(CMSFLAGS) $(CMSCOMMENT)
.MAC~.MAC :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MAC $(CMSFLAGS) $(CMSCOMMENT)
.MAR~.MAR :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MAR $(CMSFLAGS) $(CMSCOMMENT)
_______________________________________________________
Figure B-2 Cont'd on next page
B-15
Built-in Dependency Rules
Figure B-2 (Cont.) MMK default dependency rules - AXP
_______________________________________________________
.M64~.M64 :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).M64 $(CMSFLAGS) $(CMSCOMMENT)
.MMS~.MMS :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MMS $(CMSFLAGS) $(CMSCOMMENT)
.MSG~.MSG :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).MSG $(CMSFLAGS) $(CMSCOMMENT)
.OPT~.OPT :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).OPT $(CMSFLAGS) $(CMSCOMMENT)
.PAS~.PAS :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).PAS $(CMSFLAGS) $(CMSCOMMENT)
.PLI~.PLI :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).PLI $(CMSFLAGS) $(CMSCOMMENT)
.R32~.R32 :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).R32 $(CMSFLAGS) $(CMSCOMMENT)
.REQ~.REQ :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).REQ $(CMSFLAGS) $(CMSCOMMENT)
.RNH~.RNH :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNH $(CMSFLAGS) $(CMSCOMMENT)
.RNO~.RNO :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNO $(CMSFLAGS) $(CMSCOMMENT)
_______________________________________________________
Figure B-2 Cont'd on next page
B-16
Built-in Dependency Rules
Figure B-2 (Cont.) MMK default dependency rules - AXP
_______________________________________________________
.SCN~.SCN :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).SCN $(CMSFLAGS) $(CMSCOMMENT)
.SDML~.SDML :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).SDML $(CMSFLAGS) $(CMSCOMMENT)
.TXT~.TXT :
@ IF "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB $(MMS$CMS_LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).TXT $(CMSFLAGS) $(CMSCOMMENT)
_______________________________________________________
B-17
_______________________________________________________
C Using the CROSS_ALPHA Rules
The CROSS_ALPHA.MMS rules file is included with MMK
as an aid to developers working on programs that
will be run on both VAX and AXP systems. The default
dependency rules built into MMK are based on the
macros show in Table C-1. They are used by default
on both VAX and AXP systems.
Table_C-1__MMK_default_suffix_macros___________________
Macro______Suffix____Meaning___________________________
$(EXE) .EXE Executable image
$(L32) .L32 BLISS Library file
$(OBJ) .OBJ Object file
$(OLB) .OLB Object library
$(OPT)_____.OPT______Linker_options_file_______________
Since the files mentioned in the table are of a
different format on OpenVMS AXP systems, developers
wishing to do both AXP 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.
Table_C-2__CROSS_ALPHA_suffix_macros___________________
Macro______Suffix____Meaning___________________________
$(EXE) .ALPHA_ Executable image
EXE
C-1
Using the CROSS_ALPHA Rules
Table_C-2_(Cont.)__CROSS_ALPHA_suffix_macros___________
Macro______Suffix____Meaning___________________________
$(L32) .L32E BLISS Library file
$(OBJ) .ALPHA_ Object file
OBJ
$(OLB) .ALPHA_ Object library
OLB
$(OPT) .ALPHA_ Linker options file
___________OPT_________________________________________
To make all this work, you must use the macros in your
description file instead of making literal references
to the file type suffixes. For example:
PROGRAM$(EXE) : PROGRAM$(OBJ),SUBROUTINES$(OBJ),PROGRAM$(OPT)
$(LINK)$(LINKFLAGS) PROGRAM$(OPT)/OPTION
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 AXP Migration Tools and cross-compiling your AXP
objects on a VAX.
In addition to using the CROSS_ALPHA rules, MMK
provides the special macros __AXP__ and __ALPHA__,
which are predefined only when MMK is running on an
OpenVMS AXP system (it also provides the __VAX__
predefined macro for VAX-based builds). This allows
you to conditionalize your description file with the
.IFDEF directive to handle AXP- or VAX-specific cases.
C-2