CodeDevelopment

Code Development

This topic is for doing code development on VMS.

There are two strategies, using DCL or GNV.

The target environment can also be DCL / native VMS, or under GNV.

And some projects would be useful for running their programs under both environments, but need to adjust their operation to match how they where launched.

It also may be useful to have a package support both build environments. For example, the building the core modules for the GNV environment has to be able to be done in a DCL environment because it should not assume that there is an existing GNV environment.

One problem with making update or bug fixes to existing VMS ports of projects is that it can be hard to determine what was changed for VMS and why it was changed. Tracking why it was changed requires actually adding comments or some sort of release notes.

Tracking what was changed on VMS is easy if you take advantage of using VMS logical names. VMS allows using logical name search lists for building.

This allows you to use separate directory trees for the original source, the VMS specific changes, and the resulting binaries.

On a multiple architecture cluster, this allows using common source directories.

This makes it easy to identify the VMS specific changes, and prevents accidental changes to the original source.

These search lists can be used in both the GNV or DCL build environments.

There should be no reason that a build environment will not work with search lists. Setting this up should be one of the first steps for a port of a refresh of a port.

I typically use SRC_ROOT: as the concealed rooted logical name to the base of a copy of the original source code repository or snapshot. Only committed changes should be in this folder.

I then use VMS_ROOT: as the concealed rooted logical name for the directory tree for the code changes that have not been committed to the repository mirrored by SRC_ROOT:.

I then use LCL_ROOT: as the concealed rooted logical name for the directory that the files from building the project are put.

I use the logical name PRJ_ROOT: as the search list for SRC_ROOT:, VMS_ROOT:, LCL_ROOT:.

A build environment can share common SRC_ROOT: and VMS_ROOT: directories with multiple architectures and multiple VMS versions either in a cluster or using NFS served volumes, and have individual LCL_ROOT: directories. By using cloud storage through NFS or cloud change control systems, multiple developers all over the world can share the SRC_ROOT: and VMS_ROOT: directory trees.

I use a command procedure like setup_gnu_build.com (gnv.cvs.sourceforge.net) to set up the build environment. It knows how to re-root existing concealed rooted logical names. This procedure also changes the GNV$GNU: and SYS$POSIX_ROOT: to be a search list so that non-privileged users can run the Unix installation scripts to find out what the script actually installs and where.

Many of the examples for building programs at these sites are written to expect the logical name search list of PRJ_ROOT = SRC_ROOT:,VMS_ROOT:,LCL_ROOT:.

I also use the logical names SRC_ROOT1: and VMS_ROOT1: which contains copies of the SRC_ROOT: and VMS_ROOT: directories. The SRC_ROOT: and VMS_ROOT: are typically on NFS served volumes, and the VMS Backup tool can not operate on them. The SRC_ROOT1: and VMS_ROOT1: are used to stage copies of the source so backup savesets can be made on them for inclusion in the distribution kits.

For many projects, there are several different sources variants that you may want to have access to or to build against. I use the following concealed logical names for these and have a modified set up procedure like the one above that I pass a parameter to determine which logical name to use to create the SRC_ROOT: logical name.

Logical Name	Purpose
beta_root:	Where a daily tarball or pre-release tarball is unpacked.
source_root:	Location for extracting the sourceforge GNV cvs and subversion repositories.
trunk_root:	Where I fetch or pull repositories from the original projects like curl, gawk, bash.
rsync_root:	Where I use the rsync to pull down current source code, the usage is similar to trunk_root:.
vmsports_git_root:	Where I pull things that are in the vmsports git repository.
vmsports_svn_root:	Where I pull things that are in the vmsports subversion repository.
vmsports_mrcl_root:	Where I pull things that are in the vmsports mecurial repository.

For some real world examples:

Curl

For the current release of curl, since it is not a GNV component, I unpack that source tarball into vmsports_git_root: as if it were checked into vmsports. And when I release a PCSI kit for that version of curl, I will also check in the sources into the vmsports git repository.

To submit the changes back to the curl project, they really want them to be against the future version of curl that is being worked on, not the shipped version.

For the curl project, I can not build from a check out of the repository because it does not have the output of autoconf checked in. So I need to periodically unpack one of their daily tarballs into beta_root: in order to make sure that the VMS changes work with the current development build.

To submit patches, the curl maintainers want the git tool to be used against a checked out repository, so that means that I need to fetch the git repository somewhere, so I use trunk_root:.

CRTL Issues	CRTL Wrappers	Using GNV	Using DCL
Packaging	Common Problems	Repository Access	Coding Standards
Shared Images	Cloud Services	Build Tools	Documentation Links
Using Jenkins CI