Home
Managing change and releases
Learn how to manage change and release in the product.
Guide to building software on Windows
Pointers on using HCL VersionVault build tools
Learn about how to use VersionVault build tools.
Build sessions, sub-sessions, and hierarchical builds
Learn about HCL VersionVault build auditing.
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 sub-session): the build audit for the higher-level session does not contain complete information about the file system operations that affected the file.

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.
    - Running omake or clearmake
      Learn how to run omake or clearmake.
    - A simple clearmake build scenario
      clearmake is designed to let developers in makefile-based build environments continue working in their accustomed manner.
    - Accommodating build avoidance
      Learn about clearmake build avoidance.
    - Declaring source dependencies in makefiles
      To implement build avoidance based on time stamps, standard make variants require you to declare all the source file dependencies of each build target.
    - Build-order dependencies
    - clearmake build script execution and cmd.exe
      By default, clearmake invokes cmd.exe to execute build scripts. It finds cmd.exe in %SYSTEMROOT%\system32; if SYSTEMROOT is not set, clearmake uses C:\winnt as the default system root directory. If it cannot find the shell, clearmake exits.
    - Build scripts and the rm command
      It is common for a makefile to include a target whose build script invokes a command like rm to delete files.
    - Path names in CRs
      In a config record created on Windows, MVFS object path names begin with the VOB tag and do not include view tag prefixes.
    - Problems with forced builds
      Understand the problems with forced builds.
    - How clearmake interprets double-colon rules
      Double-colon rules are a special kind of makefile construct that allows several independent rules for one target, each with a possibly different build script.
    - Continuing to work during a build
      As your build progresses, other developers continue to work on their files and might check in new versions of elements that your build uses.
    - Using config spec time rules
      If you use a UCM view, your config spec is generated by HCL VersionVault. Do not add time rules to your config spec.
    - Build sessions, sub-sessions, and hierarchical builds
      Learn about HCL VersionVault build auditing.
      - Sub-sessions
        A build session can have any number of sub-sessions, all of which inherit the reference time of the build session.
      - 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.
      - 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.
      - 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 sub-session): the build audit for the higher-level session does not contain complete information about the file system operations that affected the file.
    - Build auditing and background processes
      If some conditions are met, HCL VersionVault build programs audit background processes correctly.
    - Working with incremental update tools
      The design of the build auditing capability makes it ideal for use with tools that build derived objects from scratch.
    - Temporary build audit files
      By default, omake and clearmake generate temporary build audit files in the directory identified by the TMP environment variable.
    - Adding a version string or time stamp to an executable
      There are simple techniques for incorporating a version string and/or time stamp into a C-language compiled executable.
  - 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.

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 sub-session): 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 might be written twice:

During the clearaudit build session, by the command invoked from clearaudit
During the clearmake sub-session, 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"