1.1 Overview of the ClearCase Build Scheme

Developers perform builds, along with all other work related to ClearCase, in views. Typically, developers work in separate, private views. Sometimes, a team shares a single view (for example, during a software integration period).

As described in Developing Software, each view provides a complete environment for building software that includes a particular configuration of source versions and a private work area in which you can modify source files, and use build tools to create object modules, executables, and so on.

As a build environment, each view is partially isolated from other views. Building software in one view never disturbs the work in another view, even another build of the same program at the same time. However, when working in a dynamic view, you can examine and benefit from work done previously in another dynamic view. A new build shares files created by previous builds, when appropriate. This sharing saves the time and disk space involved in building new objects that duplicate existing ones.

You can (but need not) determine what other builds have taken place in a directory, across all dynamic views. ClearCase includes tools for listing and comparing past builds.

The key to this scheme is that the project team's VOBs constitute a globally accessible repository for files created by builds, in the same way that they provide a repository for the source files that go into builds. A file produced by a software build is a derived object (DO). Associated with each derived object is a configuration record (CR), which clearmake or omake uses during subsequent builds to determine whether the DO can be reused or shared.

Figure 1 illustrates the ClearCase software build scheme.

Figure 1 Building Software with ClearCase: Isolation and Sharing

The section Dependency Tracking of MVFS and Non-MVFS Files describes how ClearCase keeps track of the objects produced by software builds. Build Avoidance describes the mechanism that enables such objects to be shared among views.

View Context Required

For a build that uses the data in one or more VOBs, the shell or command interpreter from which you invoke clearmake must have a view context. On Windows systems, you must be on the dynamic-views drive (by default, drive M) or a drive assigned to a view. If you want derived objects to be shared among views, you must be on a drive assigned to a view.

You can build objects in a standard directory, without a view context, but this disables many of clearmake's special features.

How Builds Work

In many ways, ClearCase builds adhere closely to the standard make paradigm:

1. You invoke clearmake, optionally specifying the names of one or more targets. (Such explicitly specified targets are called "goal targets.")

2. clearmake reads zero or more makefiles, each of which contains targets and their associated build scripts. It also reads zero or more build options specification (BOS) files, which supplement the information in the makefiles.

3. clearmake supplements the makefile-based software build instructions with its own built-in rules, or, when it runs in a compatibility mode, with built-in rules specific to that mode.

4. For each target, clearmake performs build avoidance, determining whether it actually needs to execute the associated build script (target rebuild). It takes into account both source dependencies (Have any changes occurred in source files used in building the target?) and build dependencies (Must other targets be updated before this one?).

5. If it decides to rebuild the target, clearmake executes its build script.

Build Reference Time and Build Sessions

clearmake takes into account the fact that as your build progresses, other developers can continue to work on their files, and may check in new versions of elements that your build uses. If your build takes an hour to complete, you do not want build scripts executed early in the build to use version 6 of a header file, and scripts executed later to use version 7 or 8. To prevent such inconsistencies, clearmake locks out any version that meets both of these conditions:

• The version is selected by a configuration specification rule that includes the LATEST version label.

• The version was checked in after the time the build began (the build reference time).

This reference-time facility applies to checked-in versions of elements only; it does not lock out changes to checked-out versions, other view-private files, and non-MVFS objects. clearmake adjusts for the fact that the system clocks on different hosts in a network may be somewhat out of sync (clock skew).

Exit Status

clearmake returns a zero exit status if all goal targets are successfully processed. It returns a nonzero exit status in two cases:

• clearmake itself detects an error, such as a syntax error in the makefile. In this case, the error message includes the string "clearmake".

• A makefile build script terminates with a nonzero exit status (for example, a compiler error).