source: CMT/v1r19/doc/todo.html@ 11

<!--
//-----------------------------------------------------------
// Copyright Christian Arnault LAL-Orsay CNRS
// arnault@lal.in2p3.fr
// See the complete license in cmt_license.txt "http://www.cecill.info". 
//-----------------------------------------------------------
-->

    <center><h1><b>ToDo list</b></h1></center>
    
    <blockquote>

      <center><i>Users are welcome to contribute to this list, by sending
      proposals to the <a href="discussion.html">discussion list</a>
      </i></center>

    </blockquote>
    <br>
    <hr>

    <blockquote>

      <center><table border>
        <tr>
          <td><center><i>Type</i></center></td>
          <td><center><i>Feature</i></center></td>
          <td><center><i>Status</i></center></td>
        </tr>

        <tr>
          <td>Implemented</td>
          <td><a href="#Support for unstructured directory organization">Support for unstructured directory organization</a></td>
          <td>Implemented in v1r14 serie</td>
        </tr>

        <tr>
          <td>Implemented</td>
          <td><a href="#Management of versions of external software in Interface packages">Management of versions of external software in Interface packages</a></td>
          <td>Implemented in v1r12p20020515</td>
        </tr>

        <tr>
          <td>Bug</td>
          <td><a href="#Calling source setup onto a standalone package">Calling "source setup" onto a standalone package</a></td>
          <td>Fixed in v1r12p20020515</td>
        </tr>

        <tr>
          <td>Implemented</td>
          <td><a href="#Advanced tag management in the requirements file">Advanced tag management in the requirements file</a></td>
          <td>Implemented in v1r14 serie</td>
        </tr>

        <tr>
          <td>Implemented</td>
          <td><a href="#Advanced tag management (2)">Advanced tag management (2)</a></td>
          <td>Implemented in v1r14 serie</td>
        </tr>

        <tr>
          <td>Proposed</td>
          <td><a href="#A new concept for binary tag management">A new concept for binary tag management : the <b>project</b></a></td>
          <td>No longer envisaged</td>
        </tr>

<!--
        <tr>
          <td>Foreseen|Bug|Proposed</td>
          <td><a href="#">-</a></td>
          <td>-</td>
        </tr>
-->

      </table></center>

    </blockquote>
    <br>
    <hr>
    <h2>Foreseen</h2>
    <blockquote>
      <ol>
        <li><i><a name="Support for unstructured directory organization"></a>Support for unstructured directory organization.</i>

          <p>
            It has been decided during the <a
              href="workshop/minutes.html#structure">first CMT workshop</a> 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.</p>
          
          <p>
            In this scheme, the following package organization would
            be permitted, in addition to the existing one:
            
          <blockquote>
            <pre>
&lt;package&gt;/cmt
         /src
         /...
            </pre>
          </blockquote>
        </p>
          
          <p>
            The version specification for this package could then be
            optionally located inside the file
            <tt>cmt/version.cmt</tt>. When found, this specification
            would be used for version checks.
          </p>

          <p>
            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
            
          <ul>
            
            <li>one environment variable CMTSTRUCTURINGSTYLE,
              taking the possible values:
              
              <ul>
                <li>with_version_directory (<i>default value</i>)</li>
                <li>without_version_directory</li>
              </ul>
            </li>

            <li>or the new following options to the cmt command:
              <ul>
                <li>-with_version_directory (<i>default value</i>)</li>
                <li>-without_version_directory</li>
              </ul>
            </li>
          </ul>
        </p>
          
          <p>The known drawbacks and limitations of this new structuring style are:
          <ul>

            <li>lack of systematic version checking possibilities
            (since the version file is optional)</li>

            <li>only one version of a given package is possible in the
            context of a given CMT path</li>

            <li>CVS actions may not be restricted to only one package
            when sub-packages exist</li>

          </ul>
        </p>

          <p>Strict backward compatibility is expected (implying that
          the two structuring styles can always coexist)</p>

          <p>A temptative implementation is currently achieved and
          will be made visible after stabilization of the v1r12.</p>

        </li>

      <br>
      <hr>
      <li><i><a name="Management of versions of external software in Interface packages"></a>Management of versions of external software in Interface packages</i></li>

      <p>As a follow up of discussions in the <a
      href="workshop/minutes.html#last minute">CMT workshop</a>, it is
      foreseen to support the new conventional macro
      <i>&lt;package&gt;_native_version</i>. This macro will be
      available to specify the exact value of the native version of
      the associated package.</p>

      <blockquote>
        <pre>
macro CLHEP_native_version "1.7.0.1"
        </pre>
      </blockquote>

      <p>When specified, this native version will appear in the "cmt
      show uses" output</p>

      <blockquote>
        <pre>
...
#   use CLHEP CLHEP-00-00-01 External (native_version=1.7.0.1)
...
        </pre>
      </blockquote>

<!-- Next item:

      <br>
      <hr>
      <li><i><a name=""></a></i>

-->

    </ol>
    </blockquote>
    
    <br>
    <hr>
    <h2>Known bugs</h2>
    <blockquote>
      <ol>
        <li><i><a name="Calling source setup onto a standalone package"></a>Calling "source setup" onto a standalone package</i>

          <p>When this operation is <i>not</i> done right in the
          package directory this produces an error:</p>

          <blockquote>
            <pre>
&gt; cd &lt;<i>somewhere</i>&gt;
&gt; source setup.sh
            </pre>
          </blockquote>

          works well, whereas:

          <blockquote>
            <pre>
&gt; source &lt;<i>somewhere</i>&gt;/setup.sh
            </pre>
          </blockquote>

          produces an error.

          <p><i>(Note that this works well for a conventional package,
          after a bug fix in v1r12)</i></p>

          <p><b>Solution:</b></p>

          <blockquote>
            <i>
              The setup.[c]sh and cleanup.[c]sh files are badly generated. The "cmt setup"
              command requires an option "-pack=cmt_standalone"
            </i>
          <blockquote>

        </li>

<!-- Next item:

      <br>
      <hr>
      <li><i><a name=""></a></i>
-->

      </ol>
    </blockquote>
    
    <br>
    <hr>
    <h2>Possible improvements (to be discussed)</h2>
    <blockquote>
      <ol>
        <li><i><a name="Advanced tag management in the requirements file"></a>Advanced tag management in the requirements file.</i>

          <p>This concerns the possibility to manipulate the tag
          associations, to add, remove association-tags or to clear
          the association-tags</p>

          <p>So far tags are defined in a requirements file by declaring associations with other tags</p>

          <blockquote>
            <pre>
tag A B C
            </pre>
          </blockquote>

          <p>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:</p>

          <ul>
            <li>tag_remove A B</li>
            <li>tag_clear A</li>
            <li>tag_apply A (<i>or apply_tag A ?</i>)</li>
          </ul>
        </li>

        <br>
        <hr>
        <li><i><a name="Advanced tag management (2)"></a>Advanced tag management (2).</i>

          <p>Another syntax evolution of the requirements file dealing
          with tag associations is the possibility to use <i>tag
          expressions</i> when specifying alternate symbol values.</p>

          <blockquote>
            <pre>
macro_append cppflags "" \
             Linux&debug " -g " \
             WIN32&debug " /G "
            </pre>
          </blockquote>

        <p>This would avoid the need to construct explicit tag mixture
        associated with new tags.</p>

        <p>Since tags are boolean values (a tag is active or inactive)
        one considers <i>and</i> and <i>or</i> operations, with the
        <b>&amp;</b> and <b>|</b> operators, with the obvious meaning
        that "A&B" is true when both A and B are true.</p>

      <br>
      <hr>
      <li><i><a name="A new concept for binary tag management"></a>A new concept for binary tag management : the <b>project</b></i></li>

        <p>Binary tags can follow different conventions according to the
        <i>sub-projects</i> where packages are defined. Currently,
        <i>policy</i> 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.</p>

        <p>
          The concept of <b>project</b> is proposed to solve this
          question, by making explicit the <i>context</i> for all
          definitions that only belong to a given project, . The
          following definitions and characteristics are proposed:
        </p>

        <ul>

          <li>CMT defines one global project by default</li>

          <li>
            So far two CMT features are candidates for being scoped by the projects:
            <ul><li>tags</li><li>patterns</li></ul>

            <p>Other features (eg. macros, sets,...) will still be
            normally transmitted in the use relationship</p>

          </li>

          <li>
            A project is specified using the following new CMT statement:
          <blockquote>
            <pre>
project &lt;project name&gt;
            </pre>
          </blockquote>
          </li>

          <li>
            Once defined in a given package, a project becomes
            <i>the</i> context project, and cannot be overridden by
            used packages (which will specify their own context project).

            <p>
              The context project is persistent in the subsequent use
              graph, unless another context project was specified
              before
            </p>

            <p>
              In the following example:
            </p>

            <img src="Images/Projects.jpg">

            <p>
              <ol>
                <li>A is in the default project (ie CMT)</li>
                <li>P1 defines the project P1</li>
                <li>P2 defines the project P2</li>
                <li>B and F directly and respectively connect to one project</li>
                <li>C, D and E transitively connect to project P1</li>
                <li>G is inside project P1 (rather than P2) since it is the <i>first</i> definition</li>
              </ol>
            </p>
          </li>

          <li>When one enters the requirements of a package, the
          context project is always empty (ie. reset to the default
          project)</li>

          <li>The first "project" statement met along the use chain
          defines the context project</li>

          <li>When leaving a requirements, the context project is
          persistent unless another one was already specified</li>

          <li>Tags and patterns defined in the default project (ie. in
          CMT) are visible in all projects</li>

          <li>A package gets its tag associations and patterns from
          its context project (and from the default project too)</li>

          <li>Tag associations and patterns from other projects are
          not visible nor active <i>by default</i></li>

          <li>
            A pattern or a tag defined in a project may be applied
            even is the context project is different through the
            following syntax:
          <blockquote>
            <pre>
apply_pattern &lt;project name&gt;.&lt;pattern name&gt;
apply_tag &lt;project name&gt;.&lt;tag name&gt;
            </pre>
          </blockquote>
          </li>

          <li>Every project is associated with a new standard tag macro

          <blockquote>
            <pre>
&lt;project&gt;tag
            </pre>
          </blockquote>

             And a new environment variable (with the same semantics as CMTCONFIG)

          <blockquote>
            <pre>
&lt;PROJECT&gt;CONFIG
            </pre>
          </blockquote>

             The project macro acts as the default value for all
             $(&lt;package&gt;_tag) macros, and the project
             configuration variable is the default for the project
             macro. Ie. the following <i>defaults</i> settings are
             considered (for any project and package) unless
             explicitly specified through usual environment variables
             or macro settings:

          <blockquote>
            <pre>
&lt;PROJECT&gt;CONFIG=${CMTCONFIG}
&lt;project&gt;tag=${&lt;PROJECT&gt;CONFIG}
&lt;package&gt;_tag=$(&lt;project&gt;tag)
            </pre>
          </blockquote>

          </li>

          <li>
             Primary tags are defined by CMT:

             <ol>
               <li>All values of <i>uname</i></li>
               <li>Compilers (gcc, egcs, CC, cxx, KAI, VC, ...)</li>
               <li>Compiler versions</li>
               <li>Main build options (debug, optimized, profiled, ...)</li>
             </ol>

             Therefore all projects can be affected when a primary tag is activated.
          </li>

        </ul>

<!-- Next item:

      <br>
      <hr>
      <li><i><a name=""></a></i></li>

-->

      </ol>
    </blockquote>

    <hr>