wiki:WPIBuild

  1. Building WarpIN (WPI) installation files for FM/2
    1. Prerequisites
    2. Building WarpIN installation files for FM/2
      1. Customizing the WPI build through environment variables.
      2. How to build the WarpIN installation files of FM/2
    3. Modifying the FM/2's WarpIN installation files
      1. Getting started
      2. Overview
      3. How to modify the WarpIN installation files for FM/2
    4. The WPI file build process

Building WarpIN (WPI) installation files for FM/2

Prerequisites

Building WarpIN installation files for FM/2

Customizing the WPI build through environment variables.

Before building WarpIN installation files for FM/2 you may want to customize the build via the following environment variables:

BUILD_FM2UTILS
By default, a WPI file is created for both FM/2 and the optional, separate FM/2 utilities package. To prevent the creation/update of the FM/2 Utilities WPI file, use SET BUILD_FM2UTILS=0.
FM2_VER
The WPI file for FM/2 is named FM2<version-string>.WPI. The <version-string> portion of the file name can be set through the FM2_VER environment variable. For example, SET FM2_VER=-3-5-9 will result in FM2-3-5-9.WPI being created/updated.
FM2UTILS_VER
The WPI file for FM/2 Utilities is named FM2UTILS<version-string>.WPI. The <version-string> portion of the file name can be set through the FM2UTILS_VER environment variable. For example, SET FM2UTILS_VER=-1-0-1 will result in FM2UTILS-1-0-1.WPI being created/updated. (NOTE: FM2UTILS rarely changes so this variable will rarely need to be set.)

How to build the WarpIN installation files of FM/2

  1. Obtain a local copy of the SVN respository of FM/2 source files.
  2. (Optional) Set environment variables to manage/customize the Warpin file creation. (See above for details.)
  3. If a WPI file for FM2 Utilities is to be built...
    1. If a FM2Utils subdirectory of the Warpin subdirectory of the FM/2 build subtree does not exist, create one.
    2. Obtain a copy of FM2UTILS.ZIP and unzip it into this FM2Utils directory.
  4. (Optional) Make any desired changes to local copies of the files within the build subtree.
  5. Build the WarpIN installation files of FM/2 using WMAKE DIST or WMAKE WPI.
  • WMAKE DIST
    • ensures that the rest of FM/2 is built and should be used every time the local copy of any FM/2 source files have been changed. WMAKE ALL does just this step.
    • performs LXLITE compression of the executables. WMAKE LXLITE does just this step.
    • builds the WPI file(s). WMAKE WPI does just this step. (See below.)
  • WMAKE WPI
    • only builds the WPI files so it is faster than WMAKE DIST.
    • will not work correctly unless WMAKE DIST has been run at least once beforehand.
    • can be used instead of WMAKE DIST by those who are only making modifications to the WarpIN installation files for FM/2 (See below.). As these programmers develop and test their changes they will be repeatedly building WPI files when the only changes that have been made is to the WarpIN-related files or environment variables:
      • warpin\fm2.wis.in (the WarpIN script)
      • warpin\bld_fm2_wpidirs.txt
      • warpin\makefile
      • various text files "read" by the script and displayed within WarpIN windows during installation
      • various REXX programs called by EXECUTE and/or DEEXECUTE statements within the script.

Modifying the FM/2's WarpIN installation files

Getting started

Before attempting to modify FM/2's WarpIN installation files one should first read and understand the WarpIN Programmer's Guide and Reference. It will acquaint you with the general, technical details of creating WPI files. Then read and become familiar with FM/2's WarpIN script, FM2.WIS.IN, which is found in the WARPIN subdirectory of the FM/2 source subtree. This will acquaint you with the specifics of how the current WarpIN installation of FM/2 is implemented.

Overview

Basically a WPI file contains a script and one or more packages. Each package contains zero or more files. The files within a package may be organized into directories. Users select packages to install and the directories into which each package is to be installed. Any directories that may exist within the package become subdirectories of the user-specified installation directory for that package.

Currently the directory structure of the build subtree and the locations of the files therein do not match the desired installation directory structure. Therefore the current build process for the WPI files includes the creation and population of "staging" directories from which the WPI file packages are created. So the "life cycle" of a file to be installed is:

  1. The FM/2 build process creates/updates the file within the build subtree
  2. The WPI portion of the build process copies these files from various locations within the build subtree into staging directories from which the files and subdirectories are then incorporated into packages within the WPI file(s)
  3. The files and subdirectories in a package are installed into the user-selected installation directory for that package during the installation of FM/2.

Changes to the FM/2 Warpin installation will fall into the following general categories:

  • Changes that only require script changes. Examples of these changes are:
    • Changes in package names
    • Changes in default proposed installation directories
    • Changes in the WPS objects created
    • Changes in the names of or parameters passed to programs run during installation or de-installation (EXECUTE/DEEXECUTE)
    • Changes to certain text displayed in WarpIN windows during installation
    • Changes in whether or not CONFIG.SYS is updated
    • Changes in if or how OS2.INI is modified
  • Changes to files referenced within the script:
    • various REXX programs run via EXECUTE and DEEXECUTE statements within the script. If these changes require different parameters, then the script will need changing, too.
    • various text files "read" by the script and displayed during the WarpIN installation of FM/2.
  • Changes which require changes to the staging process (and, possibly, changes to the script). Examples of these changes are:
    • Changes in package numbers (requires script change, too)
    • Adding new files and/or directories to be installed
    • Removing files and/or directories
    • Changes to the location where files are built or staged.
    • Changes to the names of files
    • Changes to the package numbers to which files are assigned
  • Changes to the WPI file build process itself (See below for details on the current WPI file build process.)
    • Changes to warpin\makefile
    • Changes to the programs called from warpin\makefile

How to modify the WarpIN installation files for FM/2

  • For script changes alter warpin\FM2.WIS.IN. Do NOT alter warpin\FM2.WIS!.
  • For changes to files referenced within the script, edit the appropriate files within the build subtree and update the script, if necessary.
  • For changes which require changes to the staging process:
    1. Make appropriate changes, if any, to the build process. For example:
      • Cause new or renamed files and/or directories to be created.
      • Cause discontinued files to no longer be created.
    2. Alter warpin\BLD_FM2_WPIDIRS.TXT. This file is used to control which files from which build subtree directories are to be staged into which directories of which packages. BLD_FM2_WPIDIRS.TXT is self-documented. Read it to learn how to make changes to it.
  • For changes to the WPI file build process (see below), edit the appropriate files within the build subtree.
  • When finshed with these modifications, follow the instructions above ("How to build ...") to create the new FM/2 WPI files.

The WPI file build process

The portion of the build process for FM/2 which builds the WPI files is controlled by the warpin\makefile file. For the following reasons a significant amount of the processing is delegated to REXX programs called from the makefile:

  • To build a WPI file the WarpIN executable named WIC.EXE must be functional during the build process. By default the WarpIN directory is not added to the PATH and LIBPATH when WarpIN is installed so WIC.EXE will not run from the command line without the WARPIN directory being added to both the PATH and LIBPATH. The following options were considered:
    • Use the REXX CMD file distributed with WarpIN (RUNWIC.CMD). It provides one-time executions of WIC.EXE (by temporarily modifying the PATH and LIBPATH). But it is flawed because it "breaks" other LIBPATH modifications which may have made previously. And even though this will be fixed with future distributions of WarpIN the FM/2 build process still needs to "find" RUNWIC.CMD to run it. So RUNWIC.CMD was rejected.
    • Use custom REXX programs, BLD_FM2*_WPI.CMD, which
      • Do not "break" other settings.
      • Add the Warpin directory to the PATH and (BEGIN)LIBPATH only if it is not already on those paths.
      • Relieve developers from having to add the Warpin directory manually to the PATH and LIBPATH.
  • Providing the following in an easily maintainable way without the use of REXX programs (and BLD_FM2_WPIDIRS.TXT), was beyond the makefile programming skills of the initial programmer of the WPI build process:
    • Staging only updated or missing files from the correct build subtree directories into the correct staging subdirectories for inclusion into the correct packages.
    • Changes to file names, build subtree directories and package subdirectories and/or package numbers are facilitated.
    • Ensuring that discontinued files are no longer packaged into the WPI files.

Notes on the targets of the WPI file make process and the REXX programs, if any, used to implement them:

  1. checkfiles
    1. Pupose: Determine what files, if any, need to be staged for addition to the WPI file.
    2. REXX program: ckfiles
      1. If the WPI file is missing or if the BLD_FM2_WPIDIRS.TXT file is newer than the WPI file, then BLD_FM2_WPIDIRS.TXT is copied to BLD_FM2_WPIDIRS.IN. (This causes a full rebuild of the WPI file later on.)
      2. Otherwise the BLD_FM2_WPIDIRS.TXT is read, a BLD_FM2_WPIDIRS.IN file is written which lists only the files from BLD_FM2_WPIDIRS.TXT which are new or updated (compared to the date/time of the WPI file).
  2. fm2.wis: fm2.wis.in fm2utils\fm2utils.doc fm2utils\license.txt
    1. Purpose: To incorporate the text from FM/2 Utilities text files into the FM/2 install script.
    2. This is done so that changes to these text files would not require identical changes to the FM/2 WarpIN script.
    3. SED is used to read FM2.WIS.IN and replace certain special strings with the contents of the text files, creating the final script, FM2.WIS. This is why SED is required and why changes to the script must be made to FM2.WIS.IN.
  3. fm2$(FM2_VER).wpi:: bld_fm2_wpidirs.in
    1. Purpose: Stage the files identified by the checkfiles target and then build the WPI file.
    2. REXX program: bld_fm2_wpidirs.cmd
      1. If BLD_FM2_WPIDIRS.IN is newer than the WPI file, then read it to identify which files need to be staged, where they are located in the build subtree and where they should be staged.
    3. REXX program: bld_fm2_wpi.cmd
      1. Build the WPI file from the staged files and the latest script, fm2.wis.
      2. Delete the staging directories. This prevents "moved" or discontinued files, which would otherwise linger in the staging directories, from being incorporated into future WPI files.
  4. fm2$(FM2_VER).wpi:: fm2.wis
    1. Purpose: Build the WPI file when only the script has changed.
    2. REXX program: bld_fm2_wpi.cmd
  5. fm2utils$(FM2UTILS_VER).wpi: bld_fm2utils_wpi.cmd fm2utils.wis fm2utils\fm2utils.doc fm2utils\license.txt ..\shdwmgr.cmd
    1. Purpose: Build the FM/2 Utilities WPI file
    2. REXX program: bld_fm2utils_wpi.cmd
Last modified 15 years ago Last modified on Apr 2, 2010, 10:20:39 PM
Note: See TracWiki for help on using the wiki.