Home
Managing change and releases
Learn how to manage change and release in the product.
Guide to building software on Linux and UNIX
Building software for multiple platforms
Learn how to address the challenge of using a single source tree to develop an application for a variety of hardware and software platforms.
Handling source code differences
Learn how to handle differences in the source code.

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
  - HCL 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 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
    Use clearmake effectively with C++ programs built with various compilers.
  - Using HCL VersionVault build tools with Java
    The build behavior of Java tools causes various problems for clearmake. Understand the problems and some possible solutions to resolve them.
  - Setting up a parallel build
    Learn the process to set up and run builds that use several hosts in the local area network.
  - Building software for multiple platforms
    Learn how to address the challenge of using a single source tree to develop an application for a variety of hardware and software platforms.
    - Issues in multiple platform development
      Several issues arise in an environment where developers create and maintain several platform-specific variants of an application.
    - Handling source code differences
      Learn how to handle differences in the source code.
    - Handling build procedure differences
      You can handle differences in the build procedure using the following methods.
    - Segregating the derived objects of different variants
      It is essential to keep derived objects (object modules, executables) built for different architectures separate.
    - Multiple architecture example
      Use this content as an example of multiple-architecture development.
  - Setting up a build on a non-VersionVault host
    There is a technique to create configuration records for a build that involves HCL VersionVault data, but is performed on a non-VersionVault host.
- Guide to building software on Windows

Handling source code differences

Learn how to handle differences in the source code.

Use the same files (that is, the same versions of file elements) in all builds, for all platforms. You can usually achieve this goal by using the standard UNIX system and Linux approach: conditional compilation using the C preprocessor, cpp(1). For example, if a header file string.h is to be used for the architecture whose cpp symbol is ARCH_A, and header file strings.h is to be used for architecture ARCH_B, use this code:

#ifdef ARCH_A
#include <string.h>
#else
#ifdef ARCH_B
#include <strings.h>
#endif /* ARCH_B */
#endif /* ARCH_A */

If a file element cannot be compiled conditionally (for example, a bitmap image), the traditional solution is to put architecture-specific code in different elements (for example, panel.image.x86_64 versus panel.image.ppc64le). This approach requires that build scripts be architecture specific, too.

With HCL VersionVault, you have the option of splitting the element into branches. The ARCH_A variant can be developed on the element's /main/arch_a branch; edits and builds for that variant are developed in a view configured with this rule:

element * /main/arch_a/LATEST

Other variants are developed on similar branches, each using a different view, configured with a rule as mentioned in the preceding command. In such a situation, the element's main branch might not be used at all.

Use this branching strategy only when necessary, because of its disadvantages:

Each time platform-independent code is changed on one of the branches, you must merge the change to the other branches.
Developers must create a view for each architecture. In each view, only one variant of the application can be built.

If you can do so, organize your code into architecture-specific subdirectories or architecture-specific VOBs.