| 1 | <!--
|
|---|
| 2 | //-----------------------------------------------------------
|
|---|
| 3 | // Copyright Christian Arnault LAL-Orsay CNRS
|
|---|
| 4 | // arnault@lal.in2p3.fr
|
|---|
| 5 | // See the complete license in cmt_license.txt "http://www.cecill.info".
|
|---|
| 6 | //-----------------------------------------------------------
|
|---|
| 7 | -->
|
|---|
| 8 |
|
|---|
| 9 | <center><h1><b>ToDo list</b></h1></center>
|
|---|
| 10 |
|
|---|
| 11 | <blockquote>
|
|---|
| 12 |
|
|---|
| 13 | <center><i>Users are welcome to contribute to this list, by sending
|
|---|
| 14 | proposals to the <a href="discussion.html">discussion list</a>
|
|---|
| 15 | </i></center>
|
|---|
| 16 |
|
|---|
| 17 | </blockquote>
|
|---|
| 18 | <br>
|
|---|
| 19 | <hr>
|
|---|
| 20 |
|
|---|
| 21 | <blockquote>
|
|---|
| 22 |
|
|---|
| 23 | <center><table border>
|
|---|
| 24 | <tr>
|
|---|
| 25 | <td><center><i>Type</i></center></td>
|
|---|
| 26 | <td><center><i>Feature</i></center></td>
|
|---|
| 27 | <td><center><i>Status</i></center></td>
|
|---|
| 28 | </tr>
|
|---|
| 29 |
|
|---|
| 30 | <tr>
|
|---|
| 31 | <td>Implemented</td>
|
|---|
| 32 | <td><a href="#Support for unstructured directory organization">Support for unstructured directory organization</a></td>
|
|---|
| 33 | <td>Implemented in v1r14 serie</td>
|
|---|
| 34 | </tr>
|
|---|
| 35 |
|
|---|
| 36 | <tr>
|
|---|
| 37 | <td>Implemented</td>
|
|---|
| 38 | <td><a href="#Management of versions of external software in Interface packages">Management of versions of external software in Interface packages</a></td>
|
|---|
| 39 | <td>Implemented in v1r12p20020515</td>
|
|---|
| 40 | </tr>
|
|---|
| 41 |
|
|---|
| 42 | <tr>
|
|---|
| 43 | <td>Bug</td>
|
|---|
| 44 | <td><a href="#Calling source setup onto a standalone package">Calling "source setup" onto a standalone package</a></td>
|
|---|
| 45 | <td>Fixed in v1r12p20020515</td>
|
|---|
| 46 | </tr>
|
|---|
| 47 |
|
|---|
| 48 | <tr>
|
|---|
| 49 | <td>Implemented</td>
|
|---|
| 50 | <td><a href="#Advanced tag management in the requirements file">Advanced tag management in the requirements file</a></td>
|
|---|
| 51 | <td>Implemented in v1r14 serie</td>
|
|---|
| 52 | </tr>
|
|---|
| 53 |
|
|---|
| 54 | <tr>
|
|---|
| 55 | <td>Implemented</td>
|
|---|
| 56 | <td><a href="#Advanced tag management (2)">Advanced tag management (2)</a></td>
|
|---|
| 57 | <td>Implemented in v1r14 serie</td>
|
|---|
| 58 | </tr>
|
|---|
| 59 |
|
|---|
| 60 | <tr>
|
|---|
| 61 | <td>Proposed</td>
|
|---|
| 62 | <td><a href="#A new concept for binary tag management">A new concept for binary tag management : the <b>project</b></a></td>
|
|---|
| 63 | <td>No longer envisaged</td>
|
|---|
| 64 | </tr>
|
|---|
| 65 |
|
|---|
| 66 | <!--
|
|---|
| 67 | <tr>
|
|---|
| 68 | <td>Foreseen|Bug|Proposed</td>
|
|---|
| 69 | <td><a href="#">-</a></td>
|
|---|
| 70 | <td>-</td>
|
|---|
| 71 | </tr>
|
|---|
| 72 | -->
|
|---|
| 73 |
|
|---|
| 74 | </table></center>
|
|---|
| 75 |
|
|---|
| 76 | </blockquote>
|
|---|
| 77 | <br>
|
|---|
| 78 | <hr>
|
|---|
| 79 | <h2>Foreseen</h2>
|
|---|
| 80 | <blockquote>
|
|---|
| 81 | <ol>
|
|---|
| 82 | <li><i><a name="Support for unstructured directory organization"></a>Support for unstructured directory organization.</i>
|
|---|
| 83 |
|
|---|
| 84 | <p>
|
|---|
| 85 | It has been decided during the <a
|
|---|
| 86 | href="workshop/minutes.html#structure">first CMT workshop</a> to study
|
|---|
| 87 | the possibility to support, in addition to the conventional
|
|---|
| 88 | directory structure, an alternate convention (with limited
|
|---|
| 89 | control power) where the version directory would be absent.</p>
|
|---|
| 90 |
|
|---|
| 91 | <p>
|
|---|
| 92 | In this scheme, the following package organization would
|
|---|
| 93 | be permitted, in addition to the existing one:
|
|---|
| 94 |
|
|---|
| 95 | <blockquote>
|
|---|
| 96 | <pre>
|
|---|
| 97 | <package>/cmt
|
|---|
| 98 | /src
|
|---|
| 99 | /...
|
|---|
| 100 | </pre>
|
|---|
| 101 | </blockquote>
|
|---|
| 102 | </p>
|
|---|
| 103 |
|
|---|
| 104 | <p>
|
|---|
| 105 | The version specification for this package could then be
|
|---|
| 106 | optionally located inside the file
|
|---|
| 107 | <tt>cmt/version.cmt</tt>. When found, this specification
|
|---|
| 108 | would be used for version checks.
|
|---|
| 109 | </p>
|
|---|
| 110 |
|
|---|
| 111 | <p>
|
|---|
| 112 | Each package would then individually select one or the
|
|---|
| 113 | other structuring style. This selection being done in the
|
|---|
| 114 | "cmt create" or the "cmt checkout" commands through either
|
|---|
| 115 |
|
|---|
| 116 | <ul>
|
|---|
| 117 |
|
|---|
| 118 | <li>one environment variable CMTSTRUCTURINGSTYLE,
|
|---|
| 119 | taking the possible values:
|
|---|
| 120 |
|
|---|
| 121 | <ul>
|
|---|
| 122 | <li>with_version_directory (<i>default value</i>)</li>
|
|---|
| 123 | <li>without_version_directory</li>
|
|---|
| 124 | </ul>
|
|---|
| 125 | </li>
|
|---|
| 126 |
|
|---|
| 127 | <li>or the new following options to the cmt command:
|
|---|
| 128 | <ul>
|
|---|
| 129 | <li>-with_version_directory (<i>default value</i>)</li>
|
|---|
| 130 | <li>-without_version_directory</li>
|
|---|
| 131 | </ul>
|
|---|
| 132 | </li>
|
|---|
| 133 | </ul>
|
|---|
| 134 | </p>
|
|---|
| 135 |
|
|---|
| 136 | <p>The known drawbacks and limitations of this new structuring style are:
|
|---|
| 137 | <ul>
|
|---|
| 138 |
|
|---|
| 139 | <li>lack of systematic version checking possibilities
|
|---|
| 140 | (since the version file is optional)</li>
|
|---|
| 141 |
|
|---|
| 142 | <li>only one version of a given package is possible in the
|
|---|
| 143 | context of a given CMT path</li>
|
|---|
| 144 |
|
|---|
| 145 | <li>CVS actions may not be restricted to only one package
|
|---|
| 146 | when sub-packages exist</li>
|
|---|
| 147 |
|
|---|
| 148 | </ul>
|
|---|
| 149 | </p>
|
|---|
| 150 |
|
|---|
| 151 | <p>Strict backward compatibility is expected (implying that
|
|---|
| 152 | the two structuring styles can always coexist)</p>
|
|---|
| 153 |
|
|---|
| 154 | <p>A temptative implementation is currently achieved and
|
|---|
| 155 | will be made visible after stabilization of the v1r12.</p>
|
|---|
| 156 |
|
|---|
| 157 | </li>
|
|---|
| 158 |
|
|---|
| 159 | <br>
|
|---|
| 160 | <hr>
|
|---|
| 161 | <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>
|
|---|
| 162 |
|
|---|
| 163 | <p>As a follow up of discussions in the <a
|
|---|
| 164 | href="workshop/minutes.html#last minute">CMT workshop</a>, it is
|
|---|
| 165 | foreseen to support the new conventional macro
|
|---|
| 166 | <i><package>_native_version</i>. This macro will be
|
|---|
| 167 | available to specify the exact value of the native version of
|
|---|
| 168 | the associated package.</p>
|
|---|
| 169 |
|
|---|
| 170 | <blockquote>
|
|---|
| 171 | <pre>
|
|---|
| 172 | macro CLHEP_native_version "1.7.0.1"
|
|---|
| 173 | </pre>
|
|---|
| 174 | </blockquote>
|
|---|
| 175 |
|
|---|
| 176 | <p>When specified, this native version will appear in the "cmt
|
|---|
| 177 | show uses" output</p>
|
|---|
| 178 |
|
|---|
| 179 | <blockquote>
|
|---|
| 180 | <pre>
|
|---|
| 181 | ...
|
|---|
| 182 | # use CLHEP CLHEP-00-00-01 External (native_version=1.7.0.1)
|
|---|
| 183 | ...
|
|---|
| 184 | </pre>
|
|---|
| 185 | </blockquote>
|
|---|
| 186 |
|
|---|
| 187 | <!-- Next item:
|
|---|
| 188 |
|
|---|
| 189 | <br>
|
|---|
| 190 | <hr>
|
|---|
| 191 | <li><i><a name=""></a></i>
|
|---|
| 192 |
|
|---|
| 193 | -->
|
|---|
| 194 |
|
|---|
| 195 | </ol>
|
|---|
| 196 | </blockquote>
|
|---|
| 197 |
|
|---|
| 198 | <br>
|
|---|
| 199 | <hr>
|
|---|
| 200 | <h2>Known bugs</h2>
|
|---|
| 201 | <blockquote>
|
|---|
| 202 | <ol>
|
|---|
| 203 | <li><i><a name="Calling source setup onto a standalone package"></a>Calling "source setup" onto a standalone package</i>
|
|---|
| 204 |
|
|---|
| 205 | <p>When this operation is <i>not</i> done right in the
|
|---|
| 206 | package directory this produces an error:</p>
|
|---|
| 207 |
|
|---|
| 208 | <blockquote>
|
|---|
| 209 | <pre>
|
|---|
| 210 | > cd <<i>somewhere</i>>
|
|---|
| 211 | > source setup.sh
|
|---|
| 212 | </pre>
|
|---|
| 213 | </blockquote>
|
|---|
| 214 |
|
|---|
| 215 | works well, whereas:
|
|---|
| 216 |
|
|---|
| 217 | <blockquote>
|
|---|
| 218 | <pre>
|
|---|
| 219 | > source <<i>somewhere</i>>/setup.sh
|
|---|
| 220 | </pre>
|
|---|
| 221 | </blockquote>
|
|---|
| 222 |
|
|---|
| 223 | produces an error.
|
|---|
| 224 |
|
|---|
| 225 | <p><i>(Note that this works well for a conventional package,
|
|---|
| 226 | after a bug fix in v1r12)</i></p>
|
|---|
| 227 |
|
|---|
| 228 | <p><b>Solution:</b></p>
|
|---|
| 229 |
|
|---|
| 230 | <blockquote>
|
|---|
| 231 | <i>
|
|---|
| 232 | The setup.[c]sh and cleanup.[c]sh files are badly generated. The "cmt setup"
|
|---|
| 233 | command requires an option "-pack=cmt_standalone"
|
|---|
| 234 | </i>
|
|---|
| 235 | <blockquote>
|
|---|
| 236 |
|
|---|
| 237 | </li>
|
|---|
| 238 |
|
|---|
| 239 | <!-- Next item:
|
|---|
| 240 |
|
|---|
| 241 | <br>
|
|---|
| 242 | <hr>
|
|---|
| 243 | <li><i><a name=""></a></i>
|
|---|
| 244 | -->
|
|---|
| 245 |
|
|---|
| 246 | </ol>
|
|---|
| 247 | </blockquote>
|
|---|
| 248 |
|
|---|
| 249 | <br>
|
|---|
| 250 | <hr>
|
|---|
| 251 | <h2>Possible improvements (to be discussed)</h2>
|
|---|
| 252 | <blockquote>
|
|---|
| 253 | <ol>
|
|---|
| 254 | <li><i><a name="Advanced tag management in the requirements file"></a>Advanced tag management in the requirements file.</i>
|
|---|
| 255 |
|
|---|
| 256 | <p>This concerns the possibility to manipulate the tag
|
|---|
| 257 | associations, to add, remove association-tags or to clear
|
|---|
| 258 | the association-tags</p>
|
|---|
| 259 |
|
|---|
| 260 | <p>So far tags are defined in a requirements file by declaring associations with other tags</p>
|
|---|
| 261 |
|
|---|
| 262 | <blockquote>
|
|---|
| 263 | <pre>
|
|---|
| 264 | tag A B C
|
|---|
| 265 | </pre>
|
|---|
| 266 | </blockquote>
|
|---|
| 267 |
|
|---|
| 268 | <p>The last revision of v1r12 (ie. v1r12p20020515)
|
|---|
| 269 | introduced the iterative accumulation of those
|
|---|
| 270 | associations. Therefore what is missing now is the
|
|---|
| 271 | possibility to manage this list of associations, such as
|
|---|
| 272 | with:</p>
|
|---|
| 273 |
|
|---|
| 274 | <ul>
|
|---|
| 275 | <li>tag_remove A B</li>
|
|---|
| 276 | <li>tag_clear A</li>
|
|---|
| 277 | <li>tag_apply A (<i>or apply_tag A ?</i>)</li>
|
|---|
| 278 | </ul>
|
|---|
| 279 | </li>
|
|---|
| 280 |
|
|---|
| 281 | <br>
|
|---|
| 282 | <hr>
|
|---|
| 283 | <li><i><a name="Advanced tag management (2)"></a>Advanced tag management (2).</i>
|
|---|
| 284 |
|
|---|
| 285 | <p>Another syntax evolution of the requirements file dealing
|
|---|
| 286 | with tag associations is the possibility to use <i>tag
|
|---|
| 287 | expressions</i> when specifying alternate symbol values.</p>
|
|---|
| 288 |
|
|---|
| 289 | <blockquote>
|
|---|
| 290 | <pre>
|
|---|
| 291 | macro_append cppflags "" \
|
|---|
| 292 | Linux&debug " -g " \
|
|---|
| 293 | WIN32&debug " /G "
|
|---|
| 294 | </pre>
|
|---|
| 295 | </blockquote>
|
|---|
| 296 |
|
|---|
| 297 | <p>This would avoid the need to construct explicit tag mixture
|
|---|
| 298 | associated with new tags.</p>
|
|---|
| 299 |
|
|---|
| 300 | <p>Since tags are boolean values (a tag is active or inactive)
|
|---|
| 301 | one considers <i>and</i> and <i>or</i> operations, with the
|
|---|
| 302 | <b>&</b> and <b>|</b> operators, with the obvious meaning
|
|---|
| 303 | that "A&B" is true when both A and B are true.</p>
|
|---|
| 304 |
|
|---|
| 305 | <br>
|
|---|
| 306 | <hr>
|
|---|
| 307 | <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>
|
|---|
| 308 |
|
|---|
| 309 | <p>Binary tags can follow different conventions according to the
|
|---|
| 310 | <i>sub-projects</i> where packages are defined. Currently,
|
|---|
| 311 | <i>policy</i> packages are the preferred location where these
|
|---|
| 312 | conventions are defined. However, policy packages are
|
|---|
| 313 | submitted to the usual dependency relationship, and tag
|
|---|
| 314 | associations are therefore freely transmitted across multiple
|
|---|
| 315 | policy packages, leading to conflicts and ambiguities,
|
|---|
| 316 | especially when packages from multiple and independent
|
|---|
| 317 | sub-projects are simultaneously used.</p>
|
|---|
| 318 |
|
|---|
| 319 | <p>
|
|---|
| 320 | The concept of <b>project</b> is proposed to solve this
|
|---|
| 321 | question, by making explicit the <i>context</i> for all
|
|---|
| 322 | definitions that only belong to a given project, . The
|
|---|
| 323 | following definitions and characteristics are proposed:
|
|---|
| 324 | </p>
|
|---|
| 325 |
|
|---|
| 326 | <ul>
|
|---|
| 327 |
|
|---|
| 328 | <li>CMT defines one global project by default</li>
|
|---|
| 329 |
|
|---|
| 330 | <li>
|
|---|
| 331 | So far two CMT features are candidates for being scoped by the projects:
|
|---|
| 332 | <ul><li>tags</li><li>patterns</li></ul>
|
|---|
| 333 |
|
|---|
| 334 | <p>Other features (eg. macros, sets,...) will still be
|
|---|
| 335 | normally transmitted in the use relationship</p>
|
|---|
| 336 |
|
|---|
| 337 | </li>
|
|---|
| 338 |
|
|---|
| 339 | <li>
|
|---|
| 340 | A project is specified using the following new CMT statement:
|
|---|
| 341 | <blockquote>
|
|---|
| 342 | <pre>
|
|---|
| 343 | project <project name>
|
|---|
| 344 | </pre>
|
|---|
| 345 | </blockquote>
|
|---|
| 346 | </li>
|
|---|
| 347 |
|
|---|
| 348 | <li>
|
|---|
| 349 | Once defined in a given package, a project becomes
|
|---|
| 350 | <i>the</i> context project, and cannot be overridden by
|
|---|
| 351 | used packages (which will specify their own context project).
|
|---|
| 352 |
|
|---|
| 353 | <p>
|
|---|
| 354 | The context project is persistent in the subsequent use
|
|---|
| 355 | graph, unless another context project was specified
|
|---|
| 356 | before
|
|---|
| 357 | </p>
|
|---|
| 358 |
|
|---|
| 359 | <p>
|
|---|
| 360 | In the following example:
|
|---|
| 361 | </p>
|
|---|
| 362 |
|
|---|
| 363 | <img src="Images/Projects.jpg">
|
|---|
| 364 |
|
|---|
| 365 | <p>
|
|---|
| 366 | <ol>
|
|---|
| 367 | <li>A is in the default project (ie CMT)</li>
|
|---|
| 368 | <li>P1 defines the project P1</li>
|
|---|
| 369 | <li>P2 defines the project P2</li>
|
|---|
| 370 | <li>B and F directly and respectively connect to one project</li>
|
|---|
| 371 | <li>C, D and E transitively connect to project P1</li>
|
|---|
| 372 | <li>G is inside project P1 (rather than P2) since it is the <i>first</i> definition</li>
|
|---|
| 373 | </ol>
|
|---|
| 374 | </p>
|
|---|
| 375 | </li>
|
|---|
| 376 |
|
|---|
| 377 | <li>When one enters the requirements of a package, the
|
|---|
| 378 | context project is always empty (ie. reset to the default
|
|---|
| 379 | project)</li>
|
|---|
| 380 |
|
|---|
| 381 | <li>The first "project" statement met along the use chain
|
|---|
| 382 | defines the context project</li>
|
|---|
| 383 |
|
|---|
| 384 | <li>When leaving a requirements, the context project is
|
|---|
| 385 | persistent unless another one was already specified</li>
|
|---|
| 386 |
|
|---|
| 387 | <li>Tags and patterns defined in the default project (ie. in
|
|---|
| 388 | CMT) are visible in all projects</li>
|
|---|
| 389 |
|
|---|
| 390 | <li>A package gets its tag associations and patterns from
|
|---|
| 391 | its context project (and from the default project too)</li>
|
|---|
| 392 |
|
|---|
| 393 | <li>Tag associations and patterns from other projects are
|
|---|
| 394 | not visible nor active <i>by default</i></li>
|
|---|
| 395 |
|
|---|
| 396 | <li>
|
|---|
| 397 | A pattern or a tag defined in a project may be applied
|
|---|
| 398 | even is the context project is different through the
|
|---|
| 399 | following syntax:
|
|---|
| 400 | <blockquote>
|
|---|
| 401 | <pre>
|
|---|
| 402 | apply_pattern <project name>.<pattern name>
|
|---|
| 403 | apply_tag <project name>.<tag name>
|
|---|
| 404 | </pre>
|
|---|
| 405 | </blockquote>
|
|---|
| 406 | </li>
|
|---|
| 407 |
|
|---|
| 408 | <li>Every project is associated with a new standard tag macro
|
|---|
| 409 |
|
|---|
| 410 | <blockquote>
|
|---|
| 411 | <pre>
|
|---|
| 412 | <project>tag
|
|---|
| 413 | </pre>
|
|---|
| 414 | </blockquote>
|
|---|
| 415 |
|
|---|
| 416 | And a new environment variable (with the same semantics as CMTCONFIG)
|
|---|
| 417 |
|
|---|
| 418 | <blockquote>
|
|---|
| 419 | <pre>
|
|---|
| 420 | <PROJECT>CONFIG
|
|---|
| 421 | </pre>
|
|---|
| 422 | </blockquote>
|
|---|
| 423 |
|
|---|
| 424 | The project macro acts as the default value for all
|
|---|
| 425 | $(<package>_tag) macros, and the project
|
|---|
| 426 | configuration variable is the default for the project
|
|---|
| 427 | macro. Ie. the following <i>defaults</i> settings are
|
|---|
| 428 | considered (for any project and package) unless
|
|---|
| 429 | explicitly specified through usual environment variables
|
|---|
| 430 | or macro settings:
|
|---|
| 431 |
|
|---|
| 432 | <blockquote>
|
|---|
| 433 | <pre>
|
|---|
| 434 | <PROJECT>CONFIG=${CMTCONFIG}
|
|---|
| 435 | <project>tag=${<PROJECT>CONFIG}
|
|---|
| 436 | <package>_tag=$(<project>tag)
|
|---|
| 437 | </pre>
|
|---|
| 438 | </blockquote>
|
|---|
| 439 |
|
|---|
| 440 | </li>
|
|---|
| 441 |
|
|---|
| 442 | <li>
|
|---|
| 443 | Primary tags are defined by CMT:
|
|---|
| 444 |
|
|---|
| 445 | <ol>
|
|---|
| 446 | <li>All values of <i>uname</i></li>
|
|---|
| 447 | <li>Compilers (gcc, egcs, CC, cxx, KAI, VC, ...)</li>
|
|---|
| 448 | <li>Compiler versions</li>
|
|---|
| 449 | <li>Main build options (debug, optimized, profiled, ...)</li>
|
|---|
| 450 | </ol>
|
|---|
| 451 |
|
|---|
| 452 | Therefore all projects can be affected when a primary tag is activated.
|
|---|
| 453 | </li>
|
|---|
| 454 |
|
|---|
| 455 | </ul>
|
|---|
| 456 |
|
|---|
| 457 | <!-- Next item:
|
|---|
| 458 |
|
|---|
| 459 | <br>
|
|---|
| 460 | <hr>
|
|---|
| 461 | <li><i><a name=""></a></i></li>
|
|---|
| 462 |
|
|---|
| 463 | -->
|
|---|
| 464 |
|
|---|
| 465 | </ol>
|
|---|
| 466 | </blockquote>
|
|---|
| 467 |
|
|---|
| 468 | <hr>
|
|---|
