Regularizing TMine
Now that the TMine external can be used with GlastRelease it would be good to keep the source somewhere in CVS more reputable than under users/jrb and to automate building and installation as much as possible. I propose the following:
New home in CVS
- Make a new top-levl module, TMine-scons or TMineExt-scons, in CVS
- Do a recursive copy of most of the contents of users/jrb/TMineDiv to the new module. This should preserve history.
- Make sym links for contents of SConsFiles (e.g. allExternals.scons, SConstruct, etc.) as is done for other containers
Possible gotchas
- Doing file copies and the like directly in the CVS repository makes me a little queasy. Among other things, should check that resulting files and directories have the correct file permissions.
- Versions of SConstruct, allExternals.scons, etc. used by TMine may have diverged somewhat from the official set in SConsFiles. May need to incorporate some elements from the former into the latter.
If we want to SCons to automatically build new tags it would be only a small amount of additional work. We would then have immediate feedback if the new tag failed to build properly for some OS. However note that the builds created by the SCons RM are not organized exactly as required for externals, and that there is additional hand work (new tag of IExternal/TMineExt for CMT; modifications to allExternal.scons) before a new tag of an external can actually be used by anything.
Automation
- Create two python scripts, one to check out and build a tag, another to install in a suitable location.
I've written .bat files to do these things for Windows (7.1 compiler only); python implementations should be able to handle all supported OS's and would be more flexible in other ways. The .bat files have this argument structure:
<span style="color: #008000"><strong>buildTMine</strong></span> maj min patch [debug-opt]
<span style="color: #008000"><strong>installTMine</strong></span> maj min patch [debug-opt] [destroot] [srcroot]
The first three arguments are required and specify major, minor and patch number for the cvs tag of TMine to be checked out. debug-opt defaults to opt. buildTMine checks out and builds in a subdirectory of current working directory named after the cvs tag checked out. By default installTMine will look for the build to install in the same directory buildTMine would have created, and by default installs under the directory specified by the GLAST_EXT environment variable (not directly under, but where you would expect given external name, version, etc.).
Old Stuff
This table was created Jan.27 and updated March 1.
Description |
Status |
Comments |
---|---|---|
Build TMine external for supported platforms |
Exists for Windows vc71, vc90 and rhel4 32 bit. And also mac |
This is all we need for current GR RM builds. |
Install externals in appropriate spots |
Done - |
Need ability to write to AFS GLAST_EXT (this got fixed) |
Test use in GR |
For rhel4 GlastClassify app, which links to TMine, builds and runs |
"Runs" is maybe an overstatement: it exits in orderly fashion because it wasn't called with proper args. Leon has since used it more realistically within GR. |
Create interface package for CMT |
See users/jrb/TMineExt-CMT-interface. Better yet, see IExternal/TMineExt |
|
Add entry in allExternals.scons |
Done in private copy. Done in production |
|
Modify GR requirements: remove use of TMine pkg; add one for new interface pkg |
Done |
|
Add line to externals.scons in GR-scons |
Done in private copy. Done in production |
|