...
Navid also mentioned that ROOT libraries are setup similarly to how they are handled now with a standard set of RootLibs, and a set of GUI libs.
Issues
By default, SCons searchs for tools in the site_tools directory, or the user can provide a list of tool paths. This mechanism is working except in the case of a container package such as celestialSources. Navid is trying to avoid hard-coding anything into the SConscript files and external tools. The worst case scenario is that a container will have to announce itself as such.
...
Navid is working on overriding package, aka multiple CMTPATHs.
We spoke a little about alternatives to the SCons' suggestion of automating the locating of dependencies. Jim had a method where a new environment was defined for each package. One could them import that environment and the appropriate dependencies. Some potential draw backs is that the ordering of dependencies does matter and there is a problem when working with GR and Gaudi in that the command line can get too long. Navid's method avoids those issues.
At runtime, after a build, SCons is no longer necessary.
We still need to address our use of environment variables such as <package>ROOT. Navid's commonUtilities class was created to allow pacakges to register their environment variables and perform the setenv and getenv calls. There will be a handful of remaining environment variables that must be defined a head of time, such as the location of the calibration files.