You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Mitigating the Woes of Developing and Releasing GlastRelease

* Allow ample time for GlastRelease Releases

A tag does not equal a Release in the full sense of the word.. system tests needs to be run and validated.

  • Systems Tests
    We need more people involved in running and interpreting system test results
    • Start running system tests on HEADs for P8 
    • First need to increase our disk allocation
  •  Windows Support
    •  VC90 requires full Debug externals - while Optimized requires full Opt externals
      Certainly seems we only need Debug buildsOptimized builds should be discontinued, and all Windows externals will be provided as full debug with source and distributed via the RM
  • SCons RM
    Need a better way to deal with failures (especially windows ones)
    • Unit tests and zip files periodically fail to appear 
    • Define a cron job to automatically reset the permissions on the windows zip files
  • TMine
    • Define Unit tests
    •  Reintroduce the direct use of TMine into GR, while also maintaining the TMineExt
      TMine Developers want access to TMine as a unit independent of GR
      However, we need to insure that the same version of ROOT and SConsFiles is used to build TMine in the context of GR 
      GR can use TMine and its associated packages directly via the packageList.txt, and TMine is no longer an external library.

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, most often to find the root of the package. Having this explicit in the requirements file makes this public, a plus. 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. (A fix for much of the dependency problem mentionsed above.) 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.

 MRStudio (Joanne)

 The design of MRStudio (gui layered on the core functionality) means that there can be much more commonality in the way RM does its builds and the way developers do, easing the burden of maintaining separate code to do essentially the same thing and making RM a more useful tool for debugging build problems on "the other" platform.  This project deserves high priority.

Shared Libraries for Utility Packages (Joanne)

Currently facilities and detModel are built as static libraries rather than shared (it can't be a Gaudi-style component shareable of course, but it could be linked shared, similar to xmlBase and other packages).  facilities is used by many (perhaps most) other packages.  We are forgoing the benefits of a shareable (faster linking, less duplication of binaries, easier to propagate facilities bug fixes or improvements to all packages using it) for no reason that I am aware of.  For detModel, used only by GlastSvc and the diagnostic package detCheck, the benefits are not as great, but the principle is the same. This is not a critical need, but it is an annoyance and there is some overhead involved in maintaining two branches of facilities (the main one building a static library for Gleam and ScienceTools; the other building a shareable for use in the Online environment).

  • No labels