About this task
If you need to build your software for different platforms, use the platform property to create a version of each project for each platform. These projects 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 will select the object versions matching its platform.
For example, to build the toolkit project for Windows and HP-UX®, you would copy two different versions of the project hierarchies, but set each of their platform properties to the appropriate value. (Note that you must already have set the platform values in the om_hosts.cfg file, which is discussed in Setting up platforms (page 8).)
You can give these projects meaningful versions, such as sp1_win32_2.0 or
hp_2.0. This is a great way to name your projects to identify them 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 two 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 will still pick up the version win_1, and not your merged version 2.
To fix this, you could remove the platform attributes from the old win_1 and sol_1 versions, but then you might be unable to build patches to that older release. A better fix would be to change the name of the merged object, so the older versions would no longer be candidates.
Products are also platform-specific. You will need to check out parallel branches of each product for each platform, then set the platform values appropriately.
Note: Users could build the same product for different platforms by using the same project and changing the platform property, make macros, and work area for that platform before building.
This is not a good way for users to perform builds.
Build managers need to be able to reproduce the products they build. If you are constantly changing the configuration back and forth to build different platforms, you will not be able to see how the product was built. This will make it very 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 on how update for parallel platform works, see Working with selection rules (page 78).