Home
Managing change and releases
Learn how to manage change and release in the product.
Guide to building software on Windows
Derived objects and configuration records
Learn about derived objects and configuration records.
Configuration records
A configuration record (CR) is the bill of materials for a derived object or set of DOs.
Configuration record hierarchies
A typical makefile has a hierarchical structure.

Managing change and releases
Learn how to manage change and release in the product.
- Managing software projects
- Workflow for creating projects
- Workflow for making baselines
- Workflow for recommending baselines
- Guide to building software on Linux and UNIX
- Guide to building software on Windows
  - VersionVault build concepts
    HCL VersionVault supports makefile based building of software systems and provides a software build environment closely resembling that of the make program.
  - Derived objects and configuration records
    Learn about derived objects and configuration records.
    - Derived objects overview
      Derived objects are created during builds with HCL VersionVault build tools. They are used for build avoidance and derived object sharing.
    - Configuration records
      A configuration record (CR) is the bill of materials for a derived object or set of DOs.
      - Configuration record example
        The catcr command displays the configuration record of a specified DO.
      - Contents of a configuration record
        Learn about the various sections of the configuration records.
      - Configuration record hierarchies
        A typical makefile has a hierarchical structure.
      - Configuration record cache
        When a derived object is created in a view, both its data container and its associated configuration record are stored in the private storage area of the view.
    - Kinds of derived objects
      There are two main types of derived objects (DOs), shareable DOs and non-shareable DOs. Learn about the kinds of DOs and their life cycles.
    - Reuse of DO IDs
      The DO ID for a shareable derived object is guaranteed to be unique within the VOB, for all views.
    - Derived object reference counts
      A reference count of a DO is the number of times the derived object appears in HCL VersionVault dynamic views throughout the network.
  - Pointers on using HCL VersionVault build tools
    Learn about how to use VersionVault build tools.
  - Working with DOs and configuration records
    You can perform operations on derived objects and configuration records.
  - clearmake makefiles and BOS files
    The HCL VersionVault build program, clearmake, can process makefiles.
  - Using clearmake compatibility modes
    clearmake is designed for compatibility with existing make programs, which minimizes the changes you need to make to your makefiles.
  - Using HCL VersionVault to build C++ programs
    Understand the guidelines and instructions to use the VersionVault build utilities, omake and clearmake, in C++ development environments such as Microsoft Visual C++. You will learn how the makefile fragment works and also present alternate possibilities for working around the problems.
  - Using HCL VersionVault build tools with Java
    The build behavior of Java tools causes various problems for clearmake and omake. Understand the problems and some possible solutions to resolve them.
  - Setting up a parallel build
    Learn the process to set up and run parallel builds.

Configuration record hierarchies

A typical makefile has a hierarchical structure.

A typical makefile has a hierarchical structure. Thus, running clearmake or omake once to build a high-level target can cause multiple build scripts to be executed and multiple CRs to be created. Such a set of CRs can form a configuration record hierarchy, which reflects the structure of the makefile (see the following figure).

hierarcy — Figure 1. Configuration record hierarchy

An individual parent/child link in a CR hierarchy is established in one of two ways:

In a target/dependencies line
For example, the following target/dependencies line declares derived objects hello.obj, msg.obj, and libhello.lib as build dependencies of derived object hello.exe:
```
hello.exe: hello.obj msg.obj libhello.lib
...
```
Accordingly, the CR for hello.exe is the parent of the CRs for the .obj files and the .lib file.
In a build script
For example, in the following build script, derived object libhello.lib in another directory is referenced in the build script for derived object hello.exe:
```
hello.exe: $(OBJS)
     cd ..\lib & $(MAKE) libhello.lib
     link /out: hello.exe $(OBJS) ..\lib\libhello.lib
```
Accordingly, the CR for hello.exe is the parent of the CR for libhello.lib.
Note: The recursive invocation of clearmake in the first line of this build script produces a separate CR hierarchy, which is not necessarily linked to the CR for hello.exe. The second line of the build script links the CR for ..\lib\libhello.lib with that of hello.exe by causing the link to read ..\lib\libhello.lib and making it a detected dependency.

The catcr and diffcr commands have options for handling CR hierarchies:

By default, they process individual CRs.
With the -recurse option, they process the entire CR hierarchy of each derived object specified, keeping the individual CRs separate.
With the -flat option, they combine (or flatten) the CR hierarchy of each specified derived object.

Some VersionVault features process entire CR hierarchies automatically. For example, when the mklabel command attaches version labels to all versions used to build a particular derived object (mklabel -config), it uses the entire CR hierarchy of the specified DO. Similarly, VersionVault maintenance procedures do not scrub the CR associated with a deleted DO if it is a member of the CR hierarchy of a higher-level DO.