Build avoidance

Learn how clearmake attempts to avoid rebuilding derived objects.

If an appropriate Derived Object (DO) exists in the view, clearmake reuses that DO. If there is no appropriate DO in the view, clearmake 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 Configuration Record (CR) of the candidate DO against the current build configuration of the user. 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. Actually, 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 HCL VersionVault uses guarantees that your builds are 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 build configuration of the current view. The build configuration consists of two items:

• Files: The versions of elements listed in the CR must match the versions selected by the view in which the build is performed. Any view-private files or non-MVFS files listed in the CR must also match.
• Build procedure: The build options in the CR must match the build options specified on the command line, in the environment, in makefiles, or in build options specification files. The build script listed in the CR must match the script that is executed if the target is rebuilt. The scripts are compared with all make macros expanded; thus, a match occurs only if the same build options apply (for example, compile for debugging).

The search ends when clearmake finds a DO whose configuration matches the current build configuration of the view 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 keeps them.
• Winkin: If a DO built previously matches the build configuration, clearmake causes that DO and its siblings to appear in this view. This operation is called winkin.
  Note: clearmake 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 configuration record of the DO.
• Rebuild: If configuration lookup fails to find a DO that matches the build configuration, clearmake executes the build script of the target, which creates one or more new DOs and a new CR.

Reuse and winkin take place only if clearmake determines that a newly built derived object is 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 winks in many derived objects from the existing view.