[110] | 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> |
---|