Burning Issues
External Libraries
- We're falling behind in versions in most of our external libraries. Their sources are disappearing. They are no longer supported on newer platforms (RHEL4, Macs, etc..). Examples:
- fftw (no longer has source available, doesn't compile on intel mac with gcc4)
- gaudi (no longer has source available, requires minor source changes to work on rhel4)
Unit test Failures
- we have a handful of packages in GR and (I think) one in ST whose unit tests that routinely fail or enter infinite loops.
- perhaps there should be a review of what the tests are testing (if anything)
"Pointer" Skims
- Eric Charles wrote a scheme to point to events in other files. This could be a good way to handle interleaved events and also take some of the pain out of opening N Root files in lock step. Could also come in handy for listing events to use for calibrations.
Dependencies and our use of CMT (Toby)
- Our dependencies are out of control: CMT has no way of evaluating whether the many includes for compilation, or explicit librarires for linking, are really needed. This needs a careful review of all our requirements files: are the use statements really needed? Can they be put in the private section? Should they have a "-no_auto_imports", which hides clients from unneeded dependencies? (This may then require "-imports" qualifiers.)
- Closely related to this is the fact that many such dependencies were generated by the needs of test programs. A very good example of this is RootIO, which exports a slew of dependencies to all its client packages, but has few dependencies to actually build itself.
- CMT provides a way to hide its complexities: patterns. One defines a few basic requirements files, and implements them with patterns. This was applied in the Science Tools, but we were always too busy to try to reorganize the Glast Release and Beam Test packages.
Environment variables (Toby)
Our use of CMT leaves a very heavy footprint for executables, which is a big strike against it. We are using it in a default mode in which it forces the definition of two variables for each package, namely <package>ROOT and <package>CONFIG. We never use the latter, but sometimes need the former. An example is the package Gleam: running the setup to define all the environment variables adds 255 variables! This is easy to turn off, but any such assumption then needs an alternative environment variable. This has been done for FluxSvc.
Test Programs (Toby)
We started a project to define test programs as sub-packages, allowing the dependencies to be factored. This was done for FluxSvc, with a simple convention: if a package had a subpackage named "test_<package>", then that defined a test program for the package. Such a package does not show up with a CMT "show packages" command, but it is easy to check for the existence of, say, test_FluxSvc/cmt/requirements, then, when cd'ing to that folder, CMT recognizes the package. This is supported by MRvcmt, and apparently by the RM only on Windows. This ball was dropped, needs to be put back in play.