1.4 Build Avoidance

The build tool attempts to avoid rebuilding derived objects. If an appropriate derived object exists in the view, clearmake or omake reuses that DO. If there is no appropriate DO in the view, clearmake or omake looks for an existing DO built in another view that can be winked in to the current view. The search process is called shopping.

The process of qualifying a candidate DO is called configuration lookup. It involves matching information in the VOB from the candidate DO's config record against the user's current build configuration. This process guarantees correct results in a parallel development environment, which the standard time-stamp-based algorithm used by make cannot do. Even if an object module is newer than a particular version of its source file, the module may have been built using a different version. In fact, reusing object modules and executables built recently is likely to be incorrect when rebuilding a previous release of an application from old sources. The configuration lookup algorithm that ClearCase uses guarantees that your builds will be both correct (inappropriate objects are not reused) and optimal (appropriate objects are always reused).

For a DO to be reused or winked in, the build configuration documented in its configuration record must match the current view's build configuration. The build configuration consists of two items:

The search ends when clearmake or omake finds a DO whose configuration matches the view's current build configuration exactly. In general, a configuration lookup can have three outcomes:

• Reuse. If the DO (and its siblings) in the view match the build configuration, clearmake or omake keeps them.

• Winkin. If a DO built previously matches the build configuration, clearmake or omake causes that DO and its siblings to appear in this view. This operation is termed winkin.

NOTE: The build tool does not contact all views to determine whether they contain DOs that can be winked in. Instead, it uses DO information in the VOB to eliminate inappropriate candidates. Only if it finds a candidate does it contact the containing view to retrieve the DO's configuration record.

• Rebuild. If configuration lookup fails to find a DO that matches the build configuration, clearmake or omake executes the target's build script, which creates one or more new DOs, and a new CR.

Reuse and winkin take place only if clearmake or omake determines that a newly built derived object would be identical to the existing one. Winkin takes place when two or more views select the same versions of source elements used in a build. For example, you can create another view that has the same configuration as an existing view. Initially, the new view sees all the sources but contains no derived objects. Running clearmake or omake winks in many derived objects from the existing view.

Hierarchical Builds

In a hierarchical build, some objects are built and then used to build others. The build tool performs configuration lookup separately for each target. To ensure a consistent result, the build tool also applies this principle: when a new object is created, all targets that depend on it are rebuilt. Note that winkin does not cause rebuilds of dependencies.

Automatic Dependency Detection

Configuration records enable automatic checking of source dependencies as part of build avoidance. All such dependencies (for example, on C-language header files) are logged in a build's configuration record, whether or not they are explicitly declared in a makefile.