About building on parallel platforms

If you want to build your software for different platforms, use the platform property to create a version of each project for each platform. Projects built on different and parallel platforms are called variant projects.

The variant projects share most of the same source members, but you can set different build arguments and save different resultant products in each variant project. However, it is not necessary to mark individual tasks for specific platforms, or to set up folders by platform. A single task can contain files changed for all platforms. When parallel versions occur, each project selects the object versions matching its platform.

For example, to build the toolkit project for Windows and HP-UX, copy two versions of the project hierarchies. Set each of their platform properties to the appropriate value. (You must already have set the platform values in the om_hosts.cfg file, which is discussed in Setting up platforms.)

You can give these projects meaningful versions, such as sp1_win32_2.0 or
hp_2.0. Descriptive names make your projects identifiable at a glance.

Note: If you have added a platform attribute to an object, be careful before removing it from future versions. For example, in release 1 of your product you have two parallel versions of a file, version win_1 with the platform value x86 and version sol_1 with platform value sparc. In release 2, you decide to merge these parallel files to form the cross-platform version 2, and you clear the platform attribute on version 2. Because Rational® Synergy prefers matching platform values, a project with platform value x86 still picks up the version win_1, and not your merged version 2.
To fix this, you might remove the platform attributes from the old win_1 and sol_1 versions. Then you might not be able to build patches to that older release. A better fix is to change the name of the merged object, so the older versions would no longer be candidates.

Products are also platform-specific. Check out parallel branches of each product for each platform, then set the platform values appropriately.

Note: Users might want to build the same product for different platforms by using the same project and changing the platform property, make macros, and work area before each build.
This process is not a good way for users to perform builds.

Build managers must be able to reproduce the products they build. If you are constantly changing the configuration back and forth to build different platforms, you might not be able to see how the product was built. Changing the configuration makes it hard for you to track down problems, test fixes, or preserve the software when it reaches a milestone.

Also, this method requires you to force a rebuild every time you change the platform.

For more information about how update for parallel platform works, see Working with selection rules.


Feedback