...
Code in the SConstruct file provides a mechanism similar to automake that allows users to specify the location of external libraries and their headers using with-LIBRARY, with-LIBRARY-lib and with-LIBRARY-include.
Wiki Markup with-GLAST-EXT}}. Any of the libraries found in the GLAST_EXT style layout can still be overridden with the {{with-LIBRARY\[-lib \ | \ -include\]}} options.
The code that provides the above functionality is located in externals.scons. It is responsible for locating the third party libraries and adding appropriate -L options to the compile environment. It also adds to the compile environment a list of libraries that should be linked against when a certain third party library is required.
Variant Builds
...
To allow for building the same code with different compile options, I have enabled SCons variant builds. What this means is that when a compile is performed, SCons will create a "virtual" copy of the code in a subdirectory. It will perform all builds in that directory. The directory name that is used can be modified by specifying the {{variant=}} option at the command line. If this option is not specified, SCons will determine the the OS it is running on and use that as the variant name. Additionally, it will determine if debug and/or optimized is enabled. If that is the case, it will add a {{\-debug}} and/or {{\-optimized}} to the variant name. Once the variant name is determined, builds are performed in {{\[packageName\]/build/\[variant\]}}. Once compiled in there, the libraries and other platform dependent data is installed in subdirectories that contain this variant name. For example if a build is done without specifying the {{variant=}} option on a Linux OS then the astro package would be built in {{astro/build/Linux}}. Once everything is compiled, the libraries would be installed in {{lib/Linux/}}, and the binaries would be in {{bin/Linux}}. Header files, on the other hand, would be located in {{include/}}.
Overriding packages
There are two ways two override packages. The first method you are doing a full build in your own environment with multiple versions of the same package. In the second method you are building only a few packages (again with potentially multiple versions) against an already built build version of the application.
...
| No Format |
|---|
progEnv.Tool('registerObjects', package = 'fitsGen', libraries = [fitsGenLib],
binaries = [makeFT1Bin, makeFT2Bin, makeFT2aBin, egret2FT1Bin,
convertFT1Bin, partitionBin, irfTupleBin],
includes = listFiles(['fitsGen/*.h']),
pfiles = listFiles(['pfiles/*.par']))
|
Dependency Computation
...
SCons uses something called tools. Tools are nothing more than python functions that modify the compile environment. This feature was recommended by SCons developers to use for calculating dependencies recursively. To this this a package creates a file that is {{\[packageName\]Lib.py}}. This file contains two functions {{generate()}} and {{exists()}}. The {{generate()}} function does the actual modifications of the environment while the {{exists()}} function is to give an option to disable the tool under certain conditions. Here's an example from the Likelihood package.
The LikelihoodLib.py file first defines the generate() function. This function uses the addLibrary tool to add its own libraries to the link command. It then calls the tool for other packages it directly depends on. It also calls the addLibrary tool to register external libraries it depends on.
| Warning |
|---|
It is important that only libraries that are needed for the library being added are listed here. For example liblikelihood.\[so\|a\] directly depends on astro lib. The astro library should therefore be called. Likelihood test applications might also depend on cppunit external library but they should *not* be listed here since they are not needed for linking against liblikelihood.\[so\|a\]. |
| No Format |
|---|
def generate(env, **kw):
env.Tool('addLibrary', library=['Likelihood'], package = 'Likelihood')
env.Tool('astroLib')
env.Tool('xmlBaseLib')
env.Tool('tipLib')
env.Tool('evtbinLib')
env.Tool('map_toolsLib')
env.Tool('optimizersLib')
env.Tool('irfLoaderLib')
env.Tool('st_facilitiesLib')
env.Tool('dataSubselectorLib')
env.Tool('hoopsLib')
env.Tool('st_appLib')
env.Tool('st_graphLib')
env.Tool('addLibrary', library=env['cfitsioLibs'])
env.Tool('addLibrary', library=env['fftwLibs'])
|
...
os.path.join joins 'src' and '*.cxx' together in the correct way ie \ for windows and / for linux
glob.glob then takes the src/*.cxx and gets a list of files that match that pattern
I have added a listFiles() function that'll list the files in the "virtual" environment that SCons creates.
Environment variables
...
Our use of environment variables set by CMT needs to be removed. All use of \ [PACKAGENAME\]ROOT environment variables is being removed in favor of using commonUtilities functions such as getDataPath(). Some other variables are, however, being used in parts of the code. These need to be addressed separately.
Name | Status | Solution | Used In |
|---|---|---|---|
CALDB | Needed | Set at runtime using commonUtilities::setEnvironment() | irfs/caldb, irfs/dc1Response, irfs/dc1aResponse, irfs/irfUtil |
CALDBCONFIG | Needed | Set at runtime using commonUtilities::setEnvironment() | irfs/caldb, irfs/irfUtil |
CALDBALIAS | Needed | Set at runtime using commonUtilities::setEnvironment() | irfs/caldb |
PULSAROUTFILES | Not Needed | Obtain log directory using commonUtilities::getLogPath() | celestialSources/Pulsar |
SKYMODEL_DIR | Not Needed | Remove use of this variable | celestialSources/Pulsar, Gleam |
PULSARDATA | Not Needed | Use getDataPath("Pulsar") instead | celestialSources/Pulsar, Gleam |
BYPASS_ACCUMULATOR | Unknown |
| Likelihood |
USE_OLD_LOGLIKE | Unknown |
| Likelihood |
HANDOFF_IRF_NAME | Unknown |
| irfs/handoff_response |
INTERPOLATE_EDISP | Unknown |
| irfs/handoff_response |
CALIB_DIR | Unknown |
| irfs/irfLoader |
OPTIMIZERSROOT | Unknown | Leave as is. It's written out to an xml file | optimizers |
TIMING_DIR | Unknwon | Replace with EXTFILESSYS | timeSystem |
EXTFILESSYS | Needed | Set at runtime using setupEnvironment() | various packages |
MERIT_INPUT_FILE | Unknown | Unknown | GlastClassify, merit |
MERIT_OUTPUT_FILE | Unknown | Unknown | GlastClassify, merit |
CTREE_PATH | Unknown | Unknown | GlastClassify |
PRUNEROWS | Unknown | Unknown | GlastClassify |
Fred_DIR | Not Needed | Use $GLAST_EXT/Fred/<version> | Gleam |
SKYMODEL_DIR | Unknown | Unknown | Gleam |
POINTING_HISTORY_FILE | Unknown | Unknown | Gleam |
MOOT_ARCHIVE | Unknown | Unknown | MootSvc, configData |
OBFXFCBINDIR | Unknown | Unknown | OnboardFilter |
OBFXFC_DBBINDIR | Unknown | Unknown | OnboardFilter |
OBFEFCBINDIR | Unknown | Unknown | OnboardFilter |
OBFGFC_DBBINDIR | Unknown | Unknown | OnboardFilter |
OBFCPP_DBBINDIR | Unknown | Unknown | OnboardFilter |
OBFCPG_DBBINDIR | Unknown | Unknown | OnboardFilter |
OBFGGF_DBBINDIR | Unknown | Unknown | OnboardFilter |
MYSQL_METATABLE | Unknown | Unknown | calibUtil |
MYSQL_HOST | Unknown | Unknown | calibUtil |
USER | Unknown | Unknown | calibUtil, rdbModel |
TESTJOBOPTIONS | Unknown | Unknown | gr_app |
GLEAM_CHDIR | Unknown | Unknown | gr_app |
JOBOPTIONS | Unknown | Unknown | gr_app |
stdout | Unknown | Unknown | gui |
CTREE_PATH | Unknown | Unknown | merit |
MOOT_ARCHIVE | Unknown | Unknown | mootCore |
USERNAME | Unknown | Unknown | rdbModel |
mycalibs | Unknown | Unknown | rdbModel |