BuildTools

Build Tools

This topic is about tools to help set up a build environment and also to assist in the actual build.

Many of these tools are stored in the ad hoc section of the subversion repository.

The files in the ad hoc should be considered like templates that need to be customized to a users environment or for a specific project.

Tools to help with change control

Setting up the working directory

In the article Code Development, a number of concealed logicals were shown that can help with development.

While concealed rooted logicals are useful on VMS for organizing data, one of the weak points is that in most cases they can not be nested.

So the best way to set them up is to use command procedures, like
the setup_vmsports_svn_build.com (sourceforge.net)

As this procedure depends closely on the target VMS environment, it will likely needed to be locally modified and updated.

This procedure re-roots the logical names and sets up the appropriate prj_root: search list of lcl_root:, vms_root:, and src_root: job logical names.

It also sets up job logical names for vms_root1: and src_root1: for staging the backing up of the source trees.

The input parameter of RSYNC or BETA will change where the src_root: logical name is set. BETA changes it to a beta_root: directory tree and RSYNC changes it to a rsync_root: directory tree.

This assumes of course that you have set up the concealed logical names for rsync_root, beta_root, and for where the subversion repository is checked out.

This procedure also makes a old_gnu: logical name to reference the existing GNV$GNU: or GNU: logical name if you have not switched the definition yet. A new_gnu: logical name is set up for an empty directory tree, and then locally GNV$GNU: is set up as a search list of new_gnu:,old_gnu.

Eventually there will also be similar procedures for git and mecurial.

Comparing the repository and work directories

For the src_root: and vms_root: directory trees, I have an NFS mounted volume with the system logical name vmsports_svn_root: pointing to the directory tree that is used by the NFS host to checkout and update the NFS repository.

While I could have set the vms_root: logical name to the checked out directory for the vms_source directory, I have it currently set to a work area. The only reason for this is that I prefer to examine and resolve merge conflicts my self instead of relying on the magic of the change control system. That way I know about any changes to the code that I am working on.

One weakness of NFS mounted volumes is that the VMS BACKUP tool can not back them up. That is why I have the VMS_ROOT1: and SRC_ROOT1: job logical names to point to a VMS ODS-5 volume.

Now to keep these directories in synchronization, I use a command procedure similar to compare_vmsports_source.com (sourceforge.net).

This procedure compares two directories first by checking what files are different and also what files are in one, and not the other. This procedure does need to be modified for each project because the DCL difference command only works for files with record lengths smaller than 32635 bytes. For those since we are not locally modifying them, I just have the procedure skip them.

TODO: Have the procedure check the file attributes of both files to see if the DCL

This procedure has three modes. With no parameters it compares vms_root: with the checked out [.vms_source] directory that is found based on the src_root: definition, with the assumption that src_root: is set to the checked out [.reference] directory.

If P1 is "SRCBCK", then it compares src_root: with src_root1: and if P2 is "UPDATE" it will make src_root1: up to date with src_root:

If P1 is "VMSBCK", then it compares vms_root: with vms_root1: and if P2 is update it will make vms_root1: up to date with vms_root: