Page History

...

1. For the most part environment variables pointing inside CommonExt will not be of interest to ST and GR but there are exceptions: environment variables CALDB, CALDBCONFIG and CALDBALIAS having to do with the caldb subpackage of irfs. Possible solutions include
   1. Programs in ST or GR needing these variables can call commonExtSetup::commonUtiities::setupEnvironment( ) as well as facilities::commonUtilites::setupEnvironment.  That might just work as is.
   2. If not (could be, for example, that this only works if you're running with CommonExt where it was built, not if you're running with a copy) add a new routine to commonExtSetup::commonUtilities which defines the CALDB* variables properly for use outside CommonExt
   3. Enhance SCons handling of externals somehow to export these things
2. The class st_facilities::Environment was written to simplify access to commonUtilities::setupEnvironment.  However, since st_facilities will be in CommonExt, it only has access to the internal (namespace commonExtSetup)  version of this routine.  Perhaps the same gambit used for the commonUtilities class will work here.  That is, move the st_facilities::Environment class out of the st_facililties package, into some other package outside of CommonExt. We probably could use the same new package: runtimeSetup.
3. commonUtilities.cxx has several sections starting #ifdef HEADAS .. because they organize builds somewhat differently.  I believe the copy of commonUtiliites outside of CommonExt can be left as is; I'm not sure about the one inside.  It will depend on whether FSSC chooses to build CommonExt with an organization identical to the one we use or not.