Entering Project Paths
When you enter an Integrity Lifecycle Manager configuration management project in a Project field, or when you define subproject scope for a Sandbox using a Sandbox-relative configuration path, you can specify the path and name using a flat string or a keyword-based string.
When you specify a project or configuration path and name using a flat string, there are limitations and potential ambiguities. Using a keyword-based string, you can clearly specify the correct project, even when it exists in more than one configuration. A keyword-string enables you to navigate into the configuration tree, starting with a registered project, follow the project hierarchy into subprojects, and optionally jump into the desired variant or build hierarchy as soon as it is available in the configuration path.
|
|
There are limitations to the types of jumps you can make to subprojects with different configurations. For more information, see “Rules for Jumps”. |
You can use the following keywords to specify a project path and name:
• # to specify a project or subproject in a well-formed project tree
• #n to specify a normal project
• #p to specify a top-level project that does not end with project.pj
• #s to specify a subproject that does not end with project.pj
• #d to specify the development path name
• #b to specify the number, label, or symbol of the project revision
|
|
• The order of the keywords is important. Keywords are processed from left to right to build the project specification.
• If you need to specify a # or = symbol in a keyword value, specify the symbol twice (## or ==).
• If you are specifying a variant subproject, you must specify its path starting at the root of the variant project (the project through which the development path was created).
• Specifying a Sandbox-relative configuration path using a keyword-based string applies only to Sandbox commands, and only when specifying subproject scope. The keywords #b, #d, or #n are not supported when using keywords to specify a Sandbox-relative path.
|
For example, if you had the following project setup:
/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)
where subproject shared_code/project.pj is shared with /projects/libra/project.pj, and where subproject source_code/project.pj contains co-located subprojects project.pj and project2.pj, which both share subproject colocated.pj.
You could use a keyword-based string to point to the three different configurations of the same project:
#/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
For more details on using a keyword-based string, see the options page of the CLI man pages.
Related Links
