You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Goal

Provide RM builds of GRBAnalysis for distribution.  GRBAnalysis depends somewhat loosely on ScienceTools: the BackgroundEstimator subpackage links to a few ST libraries, and other elements within GRBAnalysis make use of ST binaries.

Method

  1. Make a ScienceTools external library.  That is, for current ST tag and others in the future as needed, install the ST build (libraries, binaries, includes, python, and any other public files as needed) in the SLAC externals area, rearranging the file hierarchy somewhat to be consistent with norms in the Externals area. Add entries to allExternals.scons for this new external (known as STExt)
  2. Re-organize GRBAnalysis into standard form for a container (aka checkout package).  It will depend on STExt as well as on all the externals which ScienceTools itself depends upon.

Status

As of May 9th..

STExt

I've written a script and committed to CVS (grits-tools/python/InstallST.py) to be used to install the STExt external at SLAC for all supported Linux platforms.  Here is the help:

jrb@noric10 $ python InstallST.py --help
Usage: InstallST.py version-to-install [options]  

Options:
  -h, --help            show this help message and exit
  -a ARCH, --arch=ARCH, --architecture=ARCH
                        32 or 64  [default:value for log-in machine ]
  -o OPSYS, --os=OPSYS  rhel4 or rhel5 [default:value for log-in machine ]
  --opt, --optimized    use optimized build of ScienceTools [default] 
  --debug, --noopt      use debug build of ScienceTools
  --parent=PARENT       parent directory [default: $GLAST_EXT/STExt]
  --fake                print proposed actions but don't execute
  --real                really do it

However it doesn't yet behave entirely as advertised.  In the meantime, I've made a rhel4 32-bit STExt external for the 09-23-01 tag and have installed it in the central GLAST_EXT area. See /afs/slac/g/glast/ground/GLAST_EXT/redhat4-i686-32bit-gcc34/STExt/09.23.01 (Externals aficionados may notice that the extra compiler level - gcc34 in this case - has been omitted from the directory structure.  This was inadvertant at first, but I left it alone since there seemed to be no harm in it. The entry in allExternals has been written consistent with this organization.)

InstallST.py is now working (as of May 10).  I used it to install the 64-bit rhel4 and rhel5 builds of 09-23-01.  Could not install rhel5 32-bit because the GLAST_EXT disk for that platform was too full already.

STExt has all the installed libraries, binaries (executables; not wrapper scripts), includes, python files, data files, and system pfiles from ScienceTools-09-23-01.  Is this the right set of things?

SCons Description of STExt

Since GRBAnalysis only requires a small subset of the ScienceTools libraries (facilities, tip, astro. *Respose, irfInterface, irfLoader and rootIrfLoader) I defined a library group in allExternals.scons consisting of just these libraries called STforGRBLibs.  The SCons configure step fails, I suspect because of the mixture of shared and static libraries. It is almost certainly an artifact of the particular way the configure check is done, and not because anything is actually wrong with the libraries. For the time being I've added a new type of key in allExternals.scons allowing the definition of a library group without doing the configure check.

GRBAnalysis-scons

GRBAnalysis needs to be reorganized into a standard container.  Much of the work has been done, but not yet committed to CVS.  The BackgroundEstimator shareable builds without error against STExt. 

Still To Do

  • Create and install STExt for all other supported platforms for 09-23-01. 
  • [Would be nice] Fix InstallST.py and enlarge scope to include Mac as well as all Linux platforms so the process will be more automatic the next time a new STExt release is needed. Maybe write a separate, but relatively simple, script to handle Windows only.

  • [Would be nice] Find a way to re-instate library configure checks for  STforGRBLibs

  • Finalize file organization, naming, etc. within GRBAnalysis (which will probably have to become GRBAnalysis-scons).
  • Add SConscripts for subdirectories of GRBAnalysis which don't yet have them
  • Determine exactly what build products from GRBAnalysis need to be installed; update SConscripts accordingly.
  • Test that all build products get properly built and can run.  Check that STExt contains everything needed by GRBAnalysis.

Input Needed

For each subdirectory of GRBAnalysis I need to know what needs to be built (also how, in some cases) and what needs to be installed in order to organize the files according to standard conventions and write a suitable SConscript.

BackgroundEstimator (owner: Vlasios) This one is in good shape already.  It builds one ROOT library. SConscript is ok as it stands.

BayesianBlocks (owner: Jim) Has only one python file.  I have moved it to a directory called python for consistency with other packages.  Had no SConscript but it was easy to write one.

CompositeLightCurve (owner: Nicola?) I need to understand the contents in order to be able to organize it properly.  Is everything in there still of interest?  Should all the .py files be installed?  There is a file BayesianBlocks.py in this subpackage.  How does this relate - or does it - to the file BaysianBlocks_python.py in the BayesianBlocks subpackage?

GBMtoolkit (owner: Giacomo)  Would like to make subdirectories src (for .C) and python (for .py).  .so file does not belong in CVS. Should all the python files be installed?  If so, maybe should rename ftools.py to something less likely to cause confusion or conflicts. Once all this is straightened out, should be straightforward to make an SConscript.

GtGRB (owner: ?) Would like to make subdirectories src (or perhaps some other name, depending on how .C files are to be used) and python.  What happens to the .C files?  Should they be built into ROOT shareables or are they invoked as is, in ROOT sessions? Why are python files spread across several directories?  Should there be a GTGRB subdirectory of the python directory for the GRGRB module?  Either I need to understand much better how all these files are used, or someone who knows them has to learn something about how SCons operates.

LLE (owner: Frederic) Usual comments:  move all files except SConscript, .cvsignore out of top directory.  Determine what needs to be built; what needs to be installed. I haven't tried it yet, but the SConscript and file LLELib.py in there now look right for building the LLE library. Will have to add to SConscript if other files belonging to the package need to be installed.

vFvCL (owner: Nicola) There are only two files which, at most, get installed so there can't be much work to do here, but, with no idea what these files are for, I can't do it.

A Plea

There are several files throughout GRBAnalysis with no comments whatsoever.  Usually, but not always, the name of the file is informative, but this really isn't enough for anything you expect other people to use.  Please add a sentence or two at the top, explaining briefly what the file is for, inputs and outputs and other similar information.

  • No labels