Home
Managing change and releases
Learn how to manage change and release in the product.
Guide to building software on Windows
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 clearmake or omake instead of other make programs
clearmake and omake ensure correct reuse decisions of different versions of files selected by a config spec, determine the complete dependency list accurately with build auditing, and allow identical derived objects from other views to be winked in to the current view.

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.
  - 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 clearmake or omake instead of other make programs
      clearmake and omake ensure correct reuse decisions of different versions of files selected by a config spec, determine the complete dependency list accurately with build auditing, and allow identical derived objects from other views to be winked in to the current view.
    - Using Visual C++ with HCL VersionVault
      Learn how to use Visual C++ with VersionVault.
  - 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.

Using clearmake or omake instead of other make programs

clearmake and omake ensure correct reuse decisions of different versions of files selected by a config spec, determine the complete dependency list accurately with build auditing, and allow identical derived objects from other views to be winked in to the current view.

However, using another make program might be desirable for performance or compatibility reasons. If you use other make programs, do so with caution.

A standard make program compares the date and time of the target with that of its dependencies. If any dependency is newer than the target, make rebuilds the target. Because of configuration specifications and the winkin feature, the set of files visible in a view at any given time is very dynamic. It is common to rebuild a target because the view selects a dependency that is different, though not necessarily newer, than the one used in the previous build of the target. The HCL VersionVault build avoidance mechanism provides a more precise method of determining whether targets are up to date during builds by using the information stored in configuration records (CRs) to make correct decisions about reuse. CRs record the versions of all dependencies (whether listed in the makefile or not) of a target, rather than only the date and time of its last modification. If the version of a dependency from a CR does not match the version of the file selected by the view, clearmake or omake rebuilds the target.

The problem with using a make tool other than clearmake or omake is that the tool might make incorrect rebuild decisions if the config spec of the view is changed and different file versions are selected. However, if you are sure that the config spec will not change and that any labels used in it will not be moved to versions with earlier dates, a standard make program will make correct reuse decisions. Using the rmver command to remove a version used in a build can also change the modification time and cause make to fail to rebuild when necessary. However, this is not a recommended practice; you do not obtain the benefits of CRs and it is not realistic to assume that no one will change the config spec or move any referenced labels improperly. Because it is somewhat risky to use common make programs, use them for debug builds, not for production.