ToDo list

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


Foreseen

  1. 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.



  2. 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)
    ...
            


Known bugs

  1. Calling "source setup" onto a standalone package

    When this operation is not done right in the package directory this produces an error:

    > cd <somewhere>
    > source setup.sh
                
    works well, whereas:
    > source <somewhere>/setup.sh
                
    produces an error.

    (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"


Possible improvements (to be discussed)

  1. 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 ?)


  2. 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.



  3. 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:

      1. A is in the default project (ie CMT)
      2. P1 defines the project P1
      3. P2 defines the project P2
      4. B and F directly and respectively connect to one project
      5. C, D and E transitively connect to project P1
      6. 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
      tag
                  
      And a new environment variable (with the same semantics as CMTCONFIG)
      CONFIG
                  
      The project macro acts as the default value for all $(_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:
      1. All values of uname
      2. Compilers (gcc, egcs, CC, cxx, KAI, VC, ...)
      3. Compiler versions
      4. Main build options (debug, optimized, profiled, ...)
      Therefore all projects can be affected when a primary tag is activated.