Page History

...

• Here is a page that Traudl maintained concerning the Install Area:  http://www.slac.stanford.edu/~hansl/soft/TestInstall/^{Image Removed}
• When using the Install Area, there were problems using CMT packages installed on NFS space - often the libraries could not be found.  Apparently Traudl found some work-around, but I know I and others seemingly randomly continued to have trouble.
• From the core minutes April 20, 2004:  At least one other issue remains to be resolved: what to do about the xml file hierarchy in xmlGeoDbs. The normal install area expectation is that data files are stored in a single level.
  This would definitely be problematic as we do need some structure for the XML files since we support multiple configurations
• Toby disabled the install area by updating GlastPolicy on Oct 10, 2004 - perhaps he recalls exactly what was the major problem at the time that forced him to do this - though I'll point out..I don't recall many people were upset to see the Install Area disabled.

This CMT complaint was hand-crafted by HEATHER

4.1  re: Installation Area

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.

Joanne Bogart

5. CMT Is Too Coarse

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. 

Careful use of -no_auto_imports and other features (by those who understand them, not a group I belong to) can sometimes help, but such solutions seem to be very fragile, for example causing problems with build order. Overall, there is just too much riding on a CMT use statement.  The other tools at one's disposal, like -no_auto_imports, are essentially tinkering, and they tend to interact in unpleasant and unpredictable ways.

 Joanne Bogart

CMT Items in JIRA