Attendees: Joanne Bogart, Toby Burnett, Jim Chiang, Richard Dubois, Navid Golpayegani, Heather Kelly, Eric Winter
Note: Navid has since progressed in his SCons development and many of the examples contained in the following minutes have changed.
/
SConstruct
externals.scons List of externals and their versions. Can utilize GLAST_EXT or over-ride individual libraries. Check scons -h for available options.
(Likelihood) Directories are in ( )
(facilities)
SConscript
facilitiesLib.py <package>Lib.py lives in each package
(site_scons)
(site_tool) SCons looks here by default for tools
(include) installation location for public headers
(lib) installation location for libraries
...
Recommended fix from SCons developers is to introduce a SCons tool (a python function) which is used to update the environment. Tools are located in the site_tool directory by default, this can be over-ridden via an option when invoking the tool. There Rather than use the site_tool location, there is a <package>Lib.py file within each package. Similar 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.
...
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>/<package>*.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.
...