CMT Problems
Please report here, as precisely as you can, any general or specific problem you have with the use of CMT. Some of the problems here will probably be redeclared later as JIRA items. PLEASE GIVE YOUR NAME AT THE END OF YOUR CONTRIBUTION.
...
Container packages and directories
From R.Giannitrapani
One of the problem encountered in MRvcmt is the following: I'm using the command "cmt show packages" to have the list of the packages contained in the cmtpaths. If some packages belongs to a subdirectory of the cmtpaths and this subdirectory is not a package itself, such contained packages are not shown in the output of this command and so will not shown in the tree of MRvcmt.
...
The bug CMT-38 with Geant4 mentionned in JIRA seems fixed in v1r18. Yet, the overall problem of "cmt show packages" remains : it should be able to parse subdirectories even when they are not packages, and even if the super-package has not been checked out. At least subdirectories shoudl be parsed to a configurable depth, so that "cmt show uses" is consistent with "cmt show packages".
From D.
...
Chamont
I have the feeling there is no more problems with v1r18p20060301.
Please check.
CMTCVS Pluggin
From D.Chamont
The "cmt cvstags" command is used here and there, usually to know about the last CVS tag of a package. On top of few bugs, there is much confusion about what should be the "last" tag,
and what is the ordering of tags when displayed by "cmt cvstags".
Have a look at https://confluence.slac.stanford.edu/display/core/Tagging+Information.
About the eventual modification of the cmtcvs pluggin,
I would not filter all the tags which are returned, because it
would break the recursive check-out for some developers which
are using exotic tags for their private use.
On the other hand, I could perhaps make everyone happy if
I convince the CMT developers that the pluggin should consider
only the trunk tags when searching for the top tag. On top of that,
we could add our own collaboration-specific filtering (v*r*p*), either
in the pluggin or in each collaboration specific tool (Release
Manager, developers scripts).
2. Tag and Branch Name Confusion
From Heather
We have run into this problem both for EM and GR when creating branches. For example, if there is a tag called v6r4 on GlastPolicy and then later someone creates a branch on GlastPolicy named, ScienceTools-v6r4 - the next time we go to checkout a package using GlastPolicy v6r4 using CMT, we will receive the ScienceTools-v6r4 tag and not the v6r4 of GlastPolicy. It seems CMT searches for the first instance of the string "v6r4" rather than literally searching for just that particular tag name.
From D. Chamont
Bug reported to CMT team.
3. Version Upgrade and CVS pluggin
Original Problem.
The upgrade of CMT version requires we also replace the current CVS pluggin, which is a script, with the new C++ pluggin. This pluggin is used by several "cmt cvs*" commands.
When trying to use the new pluggin, we got two problems :
- the ordering of the ouput of command "cmt cvstags <package>" is having : the tag v0 is appearing first, where it should be the last one.
- the recursive chekcout of a release package is failing. this could come from our specific installation of the pluggin.
Status
A bug in cvstags was probably also the source of checkout failure.
I applied a small fix to the v1r1 pluggin. Reported to CMT team.
...
Installation Area
Can somebody explain why this CMT feature has been discarded ?
From Heather
I'm curious to see what others recall, but here are some notes I've found:
...
I recall having problems with picking up the right version of libraries. It's been a while now so my memory is suspect, but I think that old libraries in the Install Area maybe didn't get deleted at the expected time and would get used preferentially. Or something like that. However, I never encountered any such problems with Navid's implementation of a similar functionality, so I don't see any reason to attempt to revive the official CMT Install Area.
...
CMT runtime execution
From David Chamont
I remember to hear often people (toby, navid, richard ?) complaining about the <package>_ROOT variables generated
by CMT. What is the reason for this ? There are too much variables declared by CMT ?
...
CMT Is Too Coarse
From Joanne Bogart
Most of my complaints boil down to a lack of fine control in a natural way. As soon as there is more than one build target in a package, there are likely to be problems. As Navid mentioned, we've had trouble with multiple library targets when one should depend on the other, and trouble in general with multiple targets in a package because often they shouldn't have the same set of use statements. Private/public doesn't do the trick; the only sure way I"m aware of to deal with this is not to have multiple targets in a package unless they have similar or identical properties w.r.t. uses. The CMT use concept is also too coarse with respect to time. A package - actually, a target within a package - might need access to another at run-time but not during compile or link, or at compile and run time, but not link time. There is no way to express this with a use statement.
...