...
Recommended fix from SCons developers is to introduce a SCons tool (a python function) which is used to update the environment. Tools located in the site_tool directory by default, this can be over-ridden via an option when invoking the tool. Instead, there There is a <packagename>Lib.py file within each package. Similiar in function to CMT's "use" statements, this file lists what other packages this package requires. Only lists direct dependencies, SCons figures out the rest.
SConstruct
Next Navid provided a run-through of the contents of the SConstruct file.
Appends to the environment such as cflags. Currently this is implemented in a linux-centric fashion. This will be updated for platform independence.
Next the incDir and libDir are defined, which defines the installation directories. These are the (include) and (lib) directories specified above. Note that while the lib directory is flat, such that all libraries are stored without any subdirectories, the include directory has a structure where we have /include/<packageName>/.h All public header files will be stored in the include directory. In the case of a container package such as celestialSources, the structure would be /include/GRB/.h, so we omit the celestialSources, just as we do now with CMT. We could expand our definition of installation directories to include pfiles, xml files, jobOptions, etc.
Next a list of packages is specified, similar to a checkout package without explicit versions.
Then a function named registerObjects is defined, which accepts two arguments: packageName and list of objects. This function is called by each SConscript file within each package to register the package's objects. Set up such that we can build any package, and SCons will be able to build any other required packages as well as the requested package.
Finally, addSubPackages(topLevel, packages) causes all the SConscript files to be called.
Note for SWIG: we can ultimately eliminate the *.in files