Users are welcome to contribute to this list, by sending proposals to the discussion list
Type Feature Status Implemented Support for unstructured directory organization Implemented in v1r14 serie Implemented Management of versions of external software in Interface packages Implemented in v1r12p20020515 Bug Calling "source setup" onto a standalone package Fixed in v1r12p20020515 Implemented Advanced tag management in the requirements file Implemented in v1r14 serie Implemented Advanced tag management (2) Implemented in v1r14 serie Proposed A new concept for binary tag management : the project No longer envisaged
- Support for unstructured directory organization.
It has been decided during the first CMT workshop to study the possibility to support, in addition to the conventional directory structure, an alternate convention (with limited control power) where the version directory would be absent.
In this scheme, the following package organization would be permitted, in addition to the existing one:
/cmt /src /... The version specification for this package could then be optionally located inside the file cmt/version.cmt. When found, this specification would be used for version checks.
Each package would then individually select one or the other structuring style. This selection being done in the "cmt create" or the "cmt checkout" commands through either
- one environment variable CMTSTRUCTURINGSTYLE, taking the possible values:
- with_version_directory (default value)
- without_version_directory
- or the new following options to the cmt command:
- -with_version_directory (default value)
- -without_version_directory
The known drawbacks and limitations of this new structuring style are:
- lack of systematic version checking possibilities (since the version file is optional)
- only one version of a given package is possible in the context of a given CMT path
- CVS actions may not be restricted to only one package when sub-packages exist
Strict backward compatibility is expected (implying that the two structuring styles can always coexist)
A temptative implementation is currently achieved and will be made visible after stabilization of the v1r12.
- Management of versions of external software in Interface packages
As a follow up of discussions in the CMT workshop, it is foreseen to support the new conventional macro
_native_version . This macro will be available to specify the exact value of the native version of the associated package.macro CLHEP_native_version "1.7.0.1"When specified, this native version will appear in the "cmt show uses" output
... # use CLHEP CLHEP-00-00-01 External (native_version=1.7.0.1) ...
- Calling "source setup" onto a standalone package
When this operation is not done right in the package directory this produces an error:
works well, whereas:> cd <somewhere> > source setup.shproduces an error.> source <somewhere>/setup.sh(Note that this works well for a conventional package, after a bug fix in v1r12)
Solution:
The setup.[c]sh and cleanup.[c]sh files are badly generated. The "cmt setup" command requires an option "-pack=cmt_standalone"
- 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 CThe 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
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:
- 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- 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. apply_tag . - Every project is associated with a new standard tag macro
And a new environment variable (with the same semantics as CMTCONFIG)tag The project macro acts as the default value for all $(CONFIG _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: CONFIG=${CMTCONFIG} tag=${ CONFIG} _tag=$( tag) - Primary tags are defined by CMT:
Therefore all projects can be affected when a primary tag is activated.
- All values of uname
- Compilers (gcc, egcs, CC, cxx, KAI, VC, ...)
- Compiler versions
- Main build options (debug, optimized, profiled, ...)