Revising the build script

To produce an audited build on a non-HCL VersionVault host, you must revise the build script.

Thus, it makes sense to build in an architecture-specific subdirectory, with a customized makefile. (For more information, see Building software for multiple platforms.)

To create a CR that lists all of the input files of build and output files, the build script executed by clearmake must do the following:

• Declare all input files as explicit dependencies. Because the MVFS does not run on the non-VersionVault host, source dependencies are not detected.
• Invoke a remote shell to perform the build on the non-VersionVault host.
• If the build performed by the remote shell succeeds, run the touch(1) command on all output files from the VersionVault host. This command converts the view-private files created by the remote shell command to derived objects.

A simple build script can be transformed as follows:

Native Build

OBJS = data.o errmsg.o getcwd.o lineseq.o

data.o:

(source dependencies need not be declared)

cc -c data.c

.

.

.

(other object modules produced similarly)

libpub.a: $(OBJS)

ar -rc $@ $(OBJS)

Non-VersionVault Build

OBJS = data.o errmsg.o getcwd.o lineseq.o

data.o: data.c libpub.h

(must declare source dependencies)

rm -f $@

rsh titan 'cd /proj/libpub ; cc -c data.c'

if [ -w $@ ]; then \

touch $@ ; \

fi

.

.

.

(other object modules produced similarly)

libpub.a: $(OBJS)

rm -f $@

rsh titan 'cd /proj/libpub ; ar -rc $@ $(OBJS)'

if [ -w $@ ]; then \

touch $@ ; \

fi

The remote shell command (rsh in the preceding example) varies from system to system.

The remote shell program typically exits with a status of zero, even if the compilation fails. Thus, you must use some other technique to verify the success of the build after the remote shell returns. In this example, the build scripts assume that the remote build is successful if the target file exists and is writable.