11.7 Views for Project Builds

The config specs in this section are useful for running the various types of builds required for a project.

View That Uses Results of a Nightly Build

Many projects use scripts to run unattended software builds every night. The success or failure of these builds determine the impact of any checked-in changes on the application. In layered build environments, they can also provide up-to-date versions of lower-level software (libraries, utility programs, and so on).

Suppose that every night, a script does the following:

• Builds libraries in various subdirectories of \monet\lib

• Checks them in as DO versions in the library staging area, \monet\lib

• Labels the versions LAST_NIGHT

You can use this config spec if you want to use the libraries produced by the nightly builds:

The LAST_NIGHT version of a library is selected whenever such a version exists (Rule 2). If a nightly build fails, the previous night's build still has the LAST_NIGHT label and is selected. If no LAST_NIGHT version exists (the library is not currently under development), the stable version labeled R2_BL2 is used instead (Rule 3).

For each library, selecting versions with the LAST_NIGHT label rather than the most recent version in the staging area allows developers to stage new versions the next day, without affecting developers who use this config spec.

Variations That Select Versions of Project Libraries

The scheme described above uses version labels to select particular versions of libraries. For more flexibility, the LAST_NIGHT version of some libraries may be selected, the R2_BL2 version of others, and the most recent version of still others:

(Rule 3b is not required here, because Rule 4 handles all other libraries. It is included for clarity only.)

Other kinds of metadata can also be used to select library versions. For example, lib_selector attributes can take values such as experimental, stable, and released. A config spec can mix and match library versions like this:

View That Selects Versions of Application Subsystems

This config spec selects specific versions of the application's subsystems:

In this situation, a developer is making changes to the application's source files on the main branch (Rule 4). Builds of the application use the libraries in directory \lib that were used to build Baseline 1, and the header files in directory \include that were used to build Baseline 2.

View That Selects Versions That Built a Particular Program

This config spec defines a view that selects only enough files required to rebuild a particular program or examine its sources:

All elements that were not involved in the build of monet appear in the output of ClearCase ls with a [no version selected] annotation.

This config spec selects the versions listed in the config record (CR) of a particular derived object (and in the config records of all its build dependencies). It can be a derived object that was built in the current view, or another view, or it can be a DO version.

In this config spec, monet is a derived object in the current view. You can reference a derived object in another view with an extended pathname that includes a DO-ID:

But typically, this kind of config spec is used to configure a view from a derived object that has been checked in as a DO version.

Configuring the Makefile

By default, a derived object's config record does not list the version of the makefile that was used to build it. Instead, the CR includes a copy of the build script itself. (Why? When a new version of the makefile is created with a revision to one target's build script, the configuration records of all other derived objects built with that makefile are not rendered out of date.)

But if the monet program is to be rebuilt in this view using clearmake (or omake), a version of the makefile must be selected somehow. You can have clearmake record the makefile version in the config record by including the special clearmake macro invocation $(MAKEFILE) in the target's dependency list:

monet.exe: $(MAKEFILE) monet.obj ...
link -out:monet.exe monet.obj ...

clearmake always records the versions of explicit dependencies in the CR.

Alternatively, you can configure the makefile at the source level: attach a version label to the makefile at build time, and then use a config spec like the one in Historical View Defined by a Version Label here or View to Modify an Old Configuration here to configure a view for building. You can also use the special target .DEPENDENCY_IGNORED_FOR_REUSE; for more information, see Building Software.

Fixing Bugs in the Program

If a bug is discovered in the monet program, as rebuilt in a view that selects only enough files required to rebuild a particular program, it is easy to convert the view from a build configuration to a development configuration. As usual, when making changes in old sources, follow this strategy:

• Create a branch at each version to be modified

• Use the same branch name (that is, create an instance of the same branch type) in every element

If the fix branch type is r1_fix, this modified config spec reconfigures the view for performing the fix:

Selecting Versions That Built a Set of Programs

It is easy to expand the config spec that selects only enough files required to rebuild a particular program to configure a view with the sources used to build a set of programs, rather than a single program:

There can be version conflicts in such configurations, however. For example, different versions of file params.h may have been used in the builds of monet and xmonet. In this situation, the version used in monet is configured, because its configuration rule came first. Similarly, there can be conflicts when using a single -config rule: if the specified derived object was created by actually building some targets and using DO versions of other targets, multiple versions of some source files may be involved.

You can modify this config spec as described in Fixing Bugs in the Program, to change the build configuration to a development configuration.