ソフトウェアを異なるプラットフォーム用にビルドする場合、プラットフォーム・プロパティーを使用して、各プロジェクトの各プラットフォーム向けバージョンを作成します。異なるパラレル・プラットフォーム上でビルドされるプロジェクトは、可変プロジェクトと呼ばれます。
可変プロジェクトは同一のソース・メンバーをほぼ共有しますが、異なるビルド引数を設定して、その結果生成される異なるプロダクトを各可変プロジェクトで保存できます。ただし、個々のタスクを特定のプラットフォーム用にマーク付けしたり、プラットフォーム別のフォルダーをセットアップしたりする必要はありません。単一タスクは、すべてのプラットフォーム用に変更された複数のファイルを含むことができます。パラレル・バージョンが出現すると、各プロジェクトは、プロジェクトのプラットフォームに一致するオブジェクト・バージョンを選択します。
例えば、Windows と HP-UX 用に toolkit プロジェクトを作成する場合、2 つのバージョンのプロジェクト階層をコピーします。それらのプラットフォーム・プロパティーを適切な値に設定します。(プラットフォーム値を om_hosts.cfg ファイルに設定しておく必要があります。このことについては、プラットフォームのセットアップを参照してください。)
これらのプロジェクトには、sp1_win32_2.0 または
hp_2.0 などの意味のあるバージョンを指定できます。
分かりやすい名前を使用すると、プロジェクトが一目で識別可能になります。
注: オブジェクトにプラットフォーム属性を追加した場合、プラットフォーム属性を今後のバージョンから削除する前に注意が必要です。例えば、プロダクトのリリース 1 ではプラットフォーム値が x86 の win_1 バージョンと、プラットフォーム値が sparc のバージョン sol_1 の 2 つのパラレル・バージョンのファイルがあるとします。リリース 2 では、これらのパラレル・ファイルをマージしてクロスプラットフォームのバージョン 2 を形成することに決め、バージョン 2 のプラットフォーム属性を消去したとします。Rational® Synergy ではプラットフォーム値の一致を優先するため、プラットフォーム値が x86 のプロジェクトは、マージ後のバージョン 2 ではなく、バージョン win_1 を選出します。
これを修正するために、古い win_1 および sol_1 バージョンからプラットフォーム属性を削除する場合もあります。
そうすると、古いリリースに対してパッチをビルドできない可能性があります。
より適切な修正方法は、マージされたオブジェクトの名前を変更して、古いバージョンが候補にならないようにすることです。
プロダクトもまたプラットフォーム固有です。各プロダクトの各プラットフォーム用のパラレル分岐を確認し、適切なプラットフォーム値を設定します。
注: ユーザーは同じプロダクトを異なるプラットフォーム用にビルドする際、同じプロジェクトを使用し、プラットフォーム・プロパティー、make マクロ、およびワークエリアを変更してから各ビルドを行うことがあります。
このプロセスは、ユーザーがビルドを実行するための適切な方法ではありません。
ビルド・マネージャーは、ビルドするプロダクトを再現できる必要があります。異なるプラットフォームをビルドするために構成を変更し続けた場合、プロダクトがビルドされた方法を確認できない可能性があります。構成を変更すると、問題の追跡、修正のテスト、またはソフトウェアがマイルストーンに到達したときにソフトウェアを保存することが困難になります。
また、この方法では、プラットフォームを変更するたびに強制的に再ビルドすることが必要になります。
パラレル・プラットフォーム用の更新のしくみについては、選択ルールの処理を参照してください。