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.