This chapter describes a technique that creates configuration records for a build that involves ClearCase data, but is performed on a non-ClearCase host. Non-ClearCase access (exporting a VOB through a view) makes the data available to that host; a remote shell is invoked to perform the build on that host.
Suppose you wish to build library libpub.a for an architecture that is not currently supported by ClearCase, using a host of that architecture named titan. The VOB storage area for the library's sources is located at /vobstore/libpub.vbs on host sol. This VOB is also mounted on sol, at /proj/libpub.
A ClearCase export view allows limited access to one or more VOBs using standard NFS export facilities. Each NFS export provides remote access to one VOB through a particular view:
The VOB itself cannot be modified through the export view: versions cannot be checked out or checked in; CRs cannot be created.
Builds can be performed in the VOB through the export view; building creates view-private objects, however, not derived objects.
Several VOBs can be exported through the same view, with separate NFS exports. The exports_ccase manual page provides a detailed discussion of this subject.
The following steps enable the non-ClearCase host to access the libpub VOB. As discussed in “Setting Up an Export View for Non-ClearCase Access”, of the CASEVision™/ClearCase Administration Guide, we will avoid a “multihop” situation by co-locating the VOB storage area, the VOB mount point, and the view storage area on the same host.
Create a view through which the libpub VOB will be exported. This view must reside the same host as the VOB storage area (host sol).
% cleartool mkview -tag libpub_expvu /public/export.vws Comments for "/public/export.vws": export view for libpub VOB . Created view "/public/export.vws".
Export the mount point of the VOB (/proj/libpub) through the export view (/view/libpub_expvu). The exact procedure varies from system to system — see exports_ccase for details. For example, on a SunOS-4 host:
Edit the ClearCase-specific exports table:
% su Password: <enter root password> # vi /etc/exports.mvfs <add export entry> /view/libpub_expvu/proj/libpub -access:titan
Invoke export_mvfs to actually perform the export:
# /usr/etc/export_mvfs /view/libpub_expvu/proj/libpub
On the non-ClearCase host, a standard NFS mount is performed on the exported pathname. For example, /view/libpub_expvu/proj/libpub should be mounted at /proj/libpub (the same location at which the VOB is mounted on ClearCase hosts).
Build script revisions are required to produce an audited build on a non-ClearCase host. Thus, it makes sense to build in an architecture-specific subdirectory, with a customized Makefile. (See Chapter 14, “Building Software for Multiple Architectures,” for more on this subject.)
To enable creation of a CR that lists all of the build's input files and output files, the build script executed by clearmake must:
declare all input files as explicit dependencies — since the MVFS does not run on the non-ClearCase host, there is no automatic detection of source dependencies
invoke a remote shell to perform the actual build on the non-ClearCase host
if the build performed by the remote shell succeeded, perform a touch(1) of all output files from the ClearCase host — this turns the view-private files created by the remote shell command into derived objects.
A simple build script might be transformed as illustrated in Example 15-1.
Native build:
OBJS = data.o errmsg.o getcwd.o lineseq.o
data.o: (no source dependencies need be declared)
cc -c data.c
.
. (other object modules produced similarly)
.
libpub.a: $(OBJS)
ar -rc $@ $(OBJS)
Non-ClearCase build:
OBJS = data.o errmsg.o getcwd.o lineseq.o
data.o: data.c libpub.h
(source dependencies must be declared)
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 Example 15-1) varies from system to system
The remote shell program typically exits with status 0, even if the compilation failed. Thus, you must use some other technique for checking the success of the build, after the remote shell returns. In the example above, the build scripts assume that the remote build has been successful if the target file exists and is writable.
The following steps perform the desired build:
The script listed above specifies a particular non-ClearCase host, titan, on which remote shells are to be executed. If there is more than one non-ClearCase host on which builds are to be performed, you must generalize this script.
 | Note: Since the remote hostname is part of the build script, wink-in of derived objects built on the various hosts will fail, unless you make further modifications (for example, using clearmake -O to disable build-script checking). |