OpenMake Meister

Build Control File Syntax

A Build Control file is essentially a recipe that contains all of the components to be included in a build. It is similar to a traditional, manually coded build script in that it contains the information on how to build an executable.

The information used to generate the Build Control file is entered into the Web Client and stored on the Knowledgebase Server.  The OOMLBLDM program uses the build component information to generate an Build Control file.  In turn, OOMLOM the build engine, reads the Build Control file to determine what should be built.  The Build Control file is, therefore, a powerful element in achieving a repeatable build process.  Much like a recipe allows a cook, in theory, to recreate a meal, the Build Control file allows a Developer or Administrator to recreate a build.  As such, the Build Control file should never be altered manually.  Any adjustments to the components of a build should be made from within the Web Client interface.  Ideally, the Build Control file should be versioned along with an application's source code.

Although you will never need to manually code an Build Control file, it is helpful to understand the layout of the Build Control file.  The following is a detailed explanation of each section of a Build Control file.  The example Build Control file is for the "Main Frame Build Demo" Project for a Target - “load(asmhi)”.

Section One: Environment Variables

The first section of the Build Control file displays all of the environment variable settings necessary to perform the build.  These variables are unique to OOMLBLDM and OOMLOM and represent the particular attributes of the Project to be built.

APPL=MAINFRAME BUILD DEMO

STAGE=DEVELOPMENT

MAKEFILEDIR=

VPATH=.;//CEE.SCEEH;//CEE.SCEEH.H;

PROJECTVPATH=.;

•   The "APPL" environment variable refers to the Project name.  In this case, the Build Control file was generated for the "Mainframe Build Demo" Project. 

•   The "STAGE" environment variable refers to the Search Path name: "Development" for which the Build Control file was generated.

•     The "MAKEFILEDIR" environment variable is most often empty, as seen above.  By default, a Build Control file is generated in the user-defined Build Directory.  However, in certain cases, a developer may choose to regenerate a Build Control file in a data set other than the Build High Level qualifier.   In these cases, the "MAKEFILEDIR" environment variable indicates the alternate data set in which the developer wants to save the Build Control file.  The "MAKEFILEDIR" variable gets defined by using the "-m" flag and its associated "File Directory" parameter on the OOMLBLDM using batch JCL.

•     The "VPATH" environment variable lists all the directories included in the Search Path.  The directories are displayed in search order and separated by a semicolon.

•     The "PROJECTVPATH" environment variable lists Search Path directories that are selected as Project Directories in the Web Client.    Like the "VPATH" directories, the "PROJECTVPATH" directories are listed in search order and separated by a semicolon.

Section Two: Targets and Dependencies

The second section of the Build Control file lists the Target and Dependency components of the intended build.  The example below is the first of several Targets included in the "ACMEGREETINGS" Build Control file.

load(asmhi) : obj(hiworld)

      FINALTARGET load(asmhi)

      TARGET load(asmhi)

      PROJECTDIRS

      DBINFO

      DEFINES

      INTDIR

      BUILDTYPE Assembler Load Module

      SCRIPT zOS Link Edit JCL.sc

      OSNAME zOS

      DEBUGFLAGS LIST ALIGN

      RELEASEFLAGS LIST ALIGN

obj(hiworld) : asm(hiworld)

      FINALTARGET load(asmhi)

      TARGET obj(hiworld)

      PROJECTDIRS

      DBINFO

      DEFINES

      INTDIR

      BUILDTYPE Assembler Load Module

      SCRIPT zOS Assemble JCL.sc

      OSNAME zOS

      DEBUGFLAGS

      RELEASEFLAGS

•       The text on the first line and to the left of the colon, " load(asmhi)", is the Target name.  All of the information to the right of the colon and below the first line is Target dependencies.

•       The Target dependencies are listed to the right of the colon and below the first line. 

•       After the dependencies, the Target variables are listed:

•       The "FINAL TARGET" variable refers to the end result executable, in this case " load(asmhi) ".

•       The "TARGET" variable references the Target itself.

•       The "PROJECTDIRS" variable indicates all of the Project Datasets used by the Target's Dependencies.  If multiple Project Datasets  exist, they are concatenated and separated by a semicolon.  Eventually, OOMLOM the build engine, concatenates the "PROJECTVPATH" environment variable and the "PROJECTDIRS" Target variables. 

•       The "DBINFO" variable contains flags that are specific to the Pre-compiler and do not need to be passed to the Compiler.  In the Web Client or ISPF panel, the Pre-compile Flags get set on the Target Detail screen in the "Pre-compile Parameters" field.  For the "load(asmhi)"  Target no flags need to be passed to the Pre-compiler.

•       The "DEFINES" variable refers to Compiler Flags.  In the Web Client or ISPF panel, the Compiler Flags get set on the Target Detail screen in the "Additional Flags" field.  For the "load(asmhi)" Target no Additional Flags need to be passed to the Compiler.

•       The "INTDIR" variable indicates the Intermediate Directory if used.

•       The "BUILDTYPE" variable details the Build Type to be used when building the Target.

•       The "SCRIPT" variable indicates which Command Script should be used to execute the Compiler or Development tool commands.

•       The "OSNAME" defines the Operating System the Build Type is associated to.

•       The "DEBUGFLAGS" or "JDEBUGFLAGS" indicates the debug flags used for the build.

•       The "RELEASEFLAGS" indicates the release compile flags used for the build.

•     The "ALL" label

all : load(asmhi)

This label displays all of the Targets to be included in the Build. 

•       Scripts -  Below the "ALL" Label, is the beginning of the Command Scripts.  Scripts are managed and stored on the Knowledgebase Server.  When OOMLBLDM generates the Build Control file, it writes all scripts used for the build into the Build Control file.  This is useful for both debugging purposes and for versioning purposes.  With the Scripts embedded into the Build Control file, the build can be re-executed at any time, regardless if there is a change in the Scripts stored on the Knowledgebase Server.