Attendees: Joanne Bogart, Toby Burnett, Jim Chiang, Richard Dubois, Navid Golpayegani, Heather Kelly, Eric Winter
/
SConstruct
externals.scons
(Likelihood)
(facilities)
SConscript
facilitiesLib.py
(site_scons)
(site_tool)
(include)
(lib)
externals.scons
List of external libraries and versions. Can specify GLAST_EXT or over-ride individual libraries. scons -h will list the available options.
automated dependencies
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. 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
Layout of SConscript Files using the facilities package as an example
Python imports:
import os, glob
Import('baseEnv') Note the bug "I" for a SCons import. Also note that the objects are writable and changes will propogate to all.
Import('registerObjects'
Navid is looking for a way to make the objects read-only, but for now, we make a copy of the baseEnv so that clients will not modify it and muddy it for others.
env = baseEnv.Copy() Jim suggests supplying a function instead, Navid is planning to do that.
Now to define the facilities static library, similiarly for a shared library.
facilitiesLib = env.StaticLibrary('facilities', library name
glob.glob(os.path.join('src', '*.cxx')) glob.glob explands wildcards os.path.join inserts the appropriate slashes for each OS.
We can utilize subdirectories for the source location as well.
registerObjects('facilities', {'libraries':[facilitiesLib], 'includes':[glob.glob(os.path.join('facilities', '*.h'))
Each package contains a tool, <package>Lib.py which defines a python function according to SCons' specific form. The facilitiesLib.py file contains two functions:
generate which does the work, and exists which provides the ability to turn off the tool.
def generate(env, **kw): dictionary of keywords, which is not used now for ST where single libraries are created but GR will create packages where libraries may have different dependencies.
evn.Tool('addLibrary', library=['facilities']) to call a tool addLibrary was created by Navid. This adds the facilities to a list of libraries.
site_tools contains addLibrary
ordering in gcc matters for libs - can't find symbols otherwise. The addLibrary tool allows developers to avoid worrying about the order, and sets it up properly. addLibrary makes sure the order is correct, if the item is not already the list, add it to the end, if it is already there, move it to the end. Each library only appears once - this helps reduce the chance of creating a command line that is too long (which can occur when dealing with the Gaudi libraries).
Discussion
After building the libraries will exist in both the packages and in the installation lib directory. After the build is completed, all we need is the include and lib directories for runtime.
Jim reminded us that it would be helpful to provide a mechanism for tags such as rh9_gcc32 and rhel4, similarly for opt and debug builds. Navid could implement subdirectories with expanded English names as he's found some users are confused by our use of rh9_gcc32 for instance.
Applications using Likelihood as an example
For applications
import glob,os
Import('baseEnv')
Import('registerObjects')
env = baseEnv.Copy()
env.Tool('LikelihoodLib') The applications can depend on the Likelihood library, this too sets up the environment to handle this.
LikelihoodLib = env.StaticLibrary('Likelihood', [glob.glob(os.path.join('src','.c')), glob.glob(os.path.join('src','.cxx'))])
gtlikelihoodBin = env.Program('gtlikelihood',glob.glob(os.path.join('src','likelihood','*.cxx')))