Index: /cmtsite/table.html
===================================================================
--- /cmtsite/table.html	(revision 109)
+++ /cmtsite/table.html	(revision 110)
@@ -23,5 +23,4 @@
   <li><a href="http://svn.lal.in2p3.fr/WebSVN/CMT/" target="Contents">Repository</a></li>
   <li><a href="download.html" target="Contents">Download</a></li>
-  <li><a href="todo.html" target="Contents">ToDo list</a></li>
   <li><a href="install.html" target="Contents">Install</a></li>
   <li><a href="workshop/index.html" target="Contents">Workshop 02</a></li>
Index: /cmtsite/todo.html
===================================================================
--- /cmtsite/todo.html	(revision 110)
+++ /cmtsite/todo.html	(revision 110)
@@ -0,0 +1,468 @@
+<!--
+//-----------------------------------------------------------
+// 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>
