From Core Minutes May 8, 2007
CMT v1r18p20061003 is now in use by RM. Navid and Joanne teamed up to find the problem, which was due to non-backwards-compatible handling of CMTPATH. However, this exercise has demonstrated that we can expect no support from CMT-central. It would be prudent to come up with an alternative which would allow us to dispense with CMT altogether. There are two candidates:
- SCons-based, perhaps in conjunction with Toby's Python scripts on Windows to produce suitable project files. Jim has volunteered to write a Python package would would take our CMT requirements files as input and create SCons SConstruct files, using a subset of ScienceTools to try it out.
- A roll-your-own solution from Navid. He has already done some work on it. He doesn't have sufficient time to put into it at the moment, but likely would in a few weeks.
The plan to eliminate unnecessary environment variables and define necessary ones at run time (not before) has been on hold but is being revived. (Toby) A large fraction of the CMT-generated ones, the <package>CONFIG variables, are unused and could be dispensed with immediately. [Post-meeting Navid has confirmed this. He tagged a newGlastPolicy which turns off the generation of these variables.]
Status from Jim Chiang May 17, 2007
Here is a rudimentary first cut at using python to parse the
requirements files to deploy SConstruct build files through a checkout
package directory tree:
/nfs/farm/g/glast/u33/jchiang/SConsBuilds
The script deploySCons.py finds and reads the requiements files and
writes "SConscript" files in the src subdirectories of each package.
I use the unix find command to discover the req files, but the python
function os.path.walk could also be used to enable portability to
windows.
The top-level SConstruct file is what one uses to do the builds. In
that file, we should put the equivalent of our various policy package
patterns as python functions and Export them so that subpackage
SConstruct files can Import them as needed.
You'll note that at the bottom of the SConstruct file there are the
lines
#SConscript(os.path.join(facilitiesDir, 'src', 'SConstruct'))
#SConscript(os.path.join(tipDir, 'src', 'SConstruct'))
#SConscript(os.path.join(astroDir, 'src', 'SConstruct'))
SConscript(os.path.join(facilitiesDir, 'src', 'SConscript'))
SConscript(os.path.join(tipDir, 'src', 'SConscript'))
SConscript(os.path.join(astroDir, 'src', 'SConscript'))
If you uncomment the first three of these and comment out the last
three, SCons will do a full build using the hand-crafted "SConstruct"
files I placed in each package, whereas using the lines as is will
give you a build using the deployed SConscript files and will only try
to build the libraries.
The astro package req file has a lot of cmt code in it that is not
used in any other package so I decided not to try to have
deploySCons.py attempt to parse and replicate all that logic in
writing its SConscript files. As a result, the astro library does not
build correctly using the Sconscript files.
To build a single package, one simply does
scons <package_name>
from the top-level directory, so we can control the order in which
things are built.
FYI, the perl scripts flattenSAE and cmt2hmake.pl are what Larry Brown
and James Peachey use to create an hmake file for ScienceTools.
-Jim