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