- Advanced tag management in the requirements file.
This concerns the possibility to manipulate the tag associations, to add, remove association-tags or to clear the association-tags
So far tags are defined in a requirements file by declaring associations with other tags
tag A B C
The last revision of v1r12 (ie. v1r12p20020515) introduced the iterative accumulation of those associations. Therefore what is missing now is the possibility to manage this list of associations, such as with:
- tag_remove A B
- tag_clear A
- tag_apply A (or apply_tag A ?)
- Advanced tag management (2).
Another syntax evolution of the requirements file dealing with tag associations is the possibility to use tag expressions when specifying alternate symbol values.
macro_append cppflags "" \ Linux&debug " -g " \ WIN32&debug " /G "This would avoid the need to construct explicit tag mixture associated with new tags.
Since tags are boolean values (a tag is active or inactive) one considers and and or operations, with the & and | operators, with the obvious meaning that "A&B" is true when both A and B are true.
- A new concept for binary tag management : the project
- CMT defines one global project by default
-
So far two CMT features are candidates for being scoped by the projects:
- tags
- patterns
Other features (eg. macros, sets,...) will still be normally transmitted in the use relationship
-
A project is specified using the following new CMT statement:
project <project name>
-
Once defined in a given package, a project becomes
the context project, and cannot be overridden by
used packages (which will specify their own context project).
The context project is persistent in the subsequent use graph, unless another context project was specified before
In the following example:
- A is in the default project (ie CMT)
- P1 defines the project P1
- P2 defines the project P2
- B and F directly and respectively connect to one project
- C, D and E transitively connect to project P1
- G is inside project P1 (rather than P2) since it is the first definition
- When one enters the requirements of a package, the context project is always empty (ie. reset to the default project)
- The first "project" statement met along the use chain defines the context project
- When leaving a requirements, the context project is persistent unless another one was already specified
- Tags and patterns defined in the default project (ie. in CMT) are visible in all projects
- A package gets its tag associations and patterns from its context project (and from the default project too)
- Tag associations and patterns from other projects are not visible nor active by default
-
A pattern or a tag defined in a project may be applied
even is the context project is different through the
following syntax:
apply_pattern <project name>.<pattern name> apply_tag <project name>.<tag name>
- Every project is associated with a new standard tag macro
And a new environment variable (with the same semantics as CMTCONFIG)<project>tag
The project macro acts as the default value for all $(<package>_tag) macros, and the project configuration variable is the default for the project macro. Ie. the following defaults settings are considered (for any project and package) unless explicitly specified through usual environment variables or macro settings:<PROJECT>CONFIG
<PROJECT>CONFIG=${CMTCONFIG} <project>tag=${<PROJECT>CONFIG} <package>_tag=$(<project>tag) -
Primary tags are defined by CMT:
- All values of uname
- Compilers (gcc, egcs, CC, cxx, KAI, VC, ...)
- Compiler versions
- Main build options (debug, optimized, profiled, ...)
Binary tags can follow different conventions according to the sub-projects where packages are defined. Currently, policy packages are the preferred location where these conventions are defined. However, policy packages are submitted to the usual dependency relationship, and tag associations are therefore freely transmitted across multiple policy packages, leading to conflicts and ambiguities, especially when packages from multiple and independent sub-projects are simultaneously used.
The concept of project is proposed to solve this question, by making explicit the context for all definitions that only belong to a given project, . The following definitions and characteristics are proposed: