3.13 Build Sessions, Subsessions, and Hierarchical Builds

The following terms are used to describe the details of ClearCase build auditing:

• Invoking clearmake, omake, or clearaudit starts a build session. The time at which the build session begins becomes the build reference time for the entire build session, as described on Continuing to Work During a Build.

• During a build session, one or more target rebuilds typically take place.

• Each target rebuild involves the execution of one or more build scripts. (A double-colon target can have multiple build scripts; see How clearmake Interprets Double-Colon Rules.)

• During each target rebuild, clearmake, omake, or clearaudit conducts a build audit.

Subsessions

A build session can have any number of subsessions, all of which inherit the reference time of the build session. A subsession corresponds to a nested build or recursive make, which is started when a clearmake, omake, or clearaudit process is invoked in the process family of a higher-level clearmake, omake, or clearaudit. For example:

• Including a clearmake, omake, or clearaudit command in a makefile build script executed by clearmake, omake, or clearaudit

• Entering a clearmake, omake, or clearaudit command in an interactive process started by clearaudit

A subsession begins while a higher-level session is still conducting build audits. The subsession conducts its own build audits, independent of the audits of the higher-level session; that is, the audits are not nested or related in any way, other than that they share the same build reference time.

Versions Created During a Build Session

Any version created during a build session and selected by a LATEST config spec rule is not visible in that build session. For example, a build checks in a derived object it has created; subsequent commands in the same build session do not select the checked-in version, unless it is selected by a config spec rule that does not use the version label LATEST.

An effect of this behavior is that you cannot check in and label a version during a single build session. Instead, you must check in the version during one build session, and label the version during another build session. Use the mklabel -config command to label versions associated with a specific derived object.

Coordinating Reference Times of Several Builds

Different build sessions have different reference times. The best way to assign a series of builds the same reference time is to structure them as a single, hierarchical build.

An alternative approach is to run all the builds within the same clearaudit session. For example, you can write a batch file, multi_make.bat, that includes several invocations of clearmake, omake, or clearaudit (along with other commands). Running the script as follows ensures that all the builds are subsessions that share the same reference time:

clearaudit -c multi_make.bat

Objects Written at More Than One Level

Problems occur when the same file is written at two or more session levels (for example, a top-level build session and a subsession): the build audit for the higher-level session does not contain complete information about the file system operations that affected the file. For example:

clearaudit -c "clearmake shuffle > logfile"

The file logfile may be written twice:

• During the clearaudit build session, by the command invoked from clearaudit

• During the clearmake subsession, when the clearaudit build session is suspended

In this case, clearaudit issues this error message:

clearaudit: Error: Derived object modified; cannot be stored in VOB. Interference from another process?

To work around this limitation, postprocess the derived object at the higher level with a copy command:

clearaudit -c "clearmake shuffle > log.tmp& copy log.tmp logfile& del log.tmp"