What Works
* There is a script, offlineObf-win.py, which will take as input a CMT-style obf external and create a reorganized one which SCons can understand.
* One can check out GlastRelease-scons and run SCons with a null target
scons --with-GLAST-EXT=%GLAST_EXT% --vc7 NoTarget
or use GoGui to do the same thing and, if your external libraries are up to date, it will succeed. This doesn't build anything, but it does confirm that all the SConscript files are sensible and that external libraries and include paths are accessible and usable.
* Some packages build successfully and their test programs run successfully: nearly all of ScienceTools and some of GlastRelease
* GlastSvc can be built and its test program runs successfully as long as it's not built debug. Probably other Gaudi packages which don't depend on too much else exhibit the same behavior.
What Doesn't Work
Defining package environment variables
SCons is set up to install everything needed at run time and everything needed by package A from package B at build time (that is, B's public includes and libraries). Hence the environment variables MYPACKAGEROOT are not useful. They have been superseded with MYPACKAGEXMLPATH, MYPACKAGEDATAPATH, etc. For GlastRelease a new category was invented with memebers of the form MYPACKAGEJOBOPTIONSPATH. The definitions are made by the program (Gleam, test_xxx, etc.) itself at initialization time by calling a special routine in facilities::commonUtilities. This routine checks to see which install directories exist by trying to open them (e.g., starting from the installation directory, xml/xmlGeoDbs) and defines the corresponding environment variables (XMLGEODBSXMLPATH). The code works fine on Linux and, in a simple stand-alone program, works fine on Windows as well. But it does not work (any more, if it ever did - not clear) in the context of ScienceTools or GlastRelease.