プロジェクト パスの入力
「プロジェクト」フィールドに Windchill RV&S コンフィギュレーション管理プロジェクトを入力する場合は、フラットな文字列またはキーワードベースの文字列を使用して、プロジェクトのパスと名前を指定することができます。
フラットな文字列を使用してプロジェクトのパスと名前を指定する場合は制限があり、あいまいになる可能性があります。キーワードベースの文字列を使用してプロジェクトのパスと名前を指定する場合は、そのプロジェクトが複数の構成に存在する場合でも、正しいプロジェクトを明確に指定できます。キーワード文字列を使用すると、構成ツリー内を移動できます。最初に登録プロジェクト、次にプロジェクト階層からサブプロジェクトに移動できます。また、目的のバリアントやビルド階層が構成パスで使用できるようになるとすぐにそれらにジャンプすることもできます。
|
|
構成が異なるサブプロジェクトでは、実行できるジャンプのタイプに制限があります。詳細については、ジャンプの規則を参照してください。
|
プロジェクトのパスと名前を指定するには、次のキーワードを使用します。
• #。正しい形式のプロジェクト ツリー内のプロジェクトまたはサブプロジェクトを指定します。
• #n。標準のプロジェクトを指定します。
• #p。project.pj で終わらない最上位のプロジェクトを指定します。
• #s。project.pj で終わらないサブプロジェクトを指定します。
• #d。開発パス名を指定します。
• #b。プロジェクトリビジョンの番号、ラベル、またはプロジェクトのシンボリックリビジョンを指定します。
|
|
• キーワードの順序が重要です。プロジェクトの指定を確立する際、キーワードは左から右に処理されます。
• キーワードの値に # 記号または = 記号を指定する必要がある場合は、その記号を 2 回指定します (## または ==)。
• バリアント サブプロジェクトを指定する場合は、バリアント プロジェクト (開発パスが作成されたときに使用されたプロジェクト) のルートから始まるパスを指定する必要があります。
|
たとえば、次のプロジェクト設定があるとします。
/projects/aurora/project.pj (project)
shared_code/project.pj (shared subproject)
source_code/project.pj (subproject)
colocated.pj (co-located project)
/projects/libra/project.pj (project)
source_code/project.pj (subproject)
colocated.pj (co-located project)
/project/libra/project.pj (shared subproject)
source_code/project2.pj (subproject)
colocated.pj (co-located project)
ここで、サブプロジェクト shared_code/project.pj は、/projects/libra/project.pj で共有されます。また、サブプロジェクト source_code/project.pj には、同じ場所にあるサブプロジェクト project.pj および project2.pj (これらの両方がサブプロジェクト colocated.pj を共有します) が含まれます。
この場合は、キーワードベースの文字列を使用して、同じプロジェクトの次の 3 つの異なる構成をポイントできます。
#/projects/aurora#shared_code/source_code/project.pj#s=colocated.pj
#/projects/libra#source_code/project.pj#s=colocated.pj
#/projects/libra#s=source_code/project2.pj#s=colocated.pj
キーワードベースの文字列の使用の詳細については、『CLI マニュアルページ 』のオプションのページを参照してください。
ジャンプの規則
プロジェクト パス内の特定の構成にジャンプする場合は、次の規則が適用されます。
• ビルド プロジェクトからはどの場所にもジャンプできません。
• 標準プロジェクトからバリアントにジャンプできるのは、そのプロジェクトがそのバリアントのルート (開発パスが作成されたときに使用されたプロジェクト) である場合に限られます。
• プロジェクト階層内の最も近い上位バリアントではない場合、そのバリアントにはジャンプできません (上位のバリアントが存在する場合)。階層内でバリアントとして構成されているサブプロジェクトが存在しない場合、最も近いバリアントが最上位プロジェクトのバリアントになります。階層内の 1 つ以上のサブプロジェクトがバリアントとして構成されている場合、最も近いバリアントが最下位に構成されているサブプロジェクトのバリアントになります。これには、ジャンプが指定されているサブプロジェクトのバリアント (現在バリアントとして構成されている場合) は含まれません。
最後の 2 つの規則は、親プロジェクトのタイプに基づいて確認されます。
|
|
上記の規則に違反している場合でも、必ずサブプロジェクトの現在の構成にジャンプできます。
|
例: バリアントへのジャンプ
次のプロジェクト設定があるとします。
/projects/aurora/source_code/savings_tool/project.pj
ここで source_code は現在 beta_variant として構成されているサブプロジェクトであり、savings_tool は現在標準として構成されているサブプロジェクトです。この場合は、次のジャンプが許可されます。
#/projects/aurora#source_code/savings_tool#d=beta_variant
次のジャンプは許可されません。
#/projects/aurora#source_code/savings_tool#d=prod_variant
サブプロジェクト savings_tool から beta_variant へのジャンプは指定できます。これは、このサブプロジェクトが source_code のバリアントと同じであり、共有サブプロジェクトとしてローカルのバリアント ルート (開発パスが作成されたときに使用されたコンフィギュレーション管理プロジェクト) として受け入れられるためです。prod_variant にはジャンプできません。これは、source_code のバリアントと異なるためです。
