Attendees:  Joanne Bogart, Richard Dubois, Navid Golpayegani, Heather Kelly, Tracy Usher

RM Status

RMViewer 1.0RC1, which includes a live tag collector, is consider the first release.  We would of course appreciate more user trials and suggestions.  There will be further tweaks for the uesr interface and performance.  Later for version 2, new features to control RM activity such as triggering and deleting builds, will be added.

Richard asked about documentation in the workbook.  There is a start in Confluence based on a much older version of RMViewer.  So far, what we've agreed to is providing doc in Confluence while applications such as RMViewer remain fluid.  This will limit Chuck's headaches, and allow him to point at the Confluence page from the workbook.

Navid continues to work on the wrapper scripts on Windows to address fully handling the supercede capability.  Once that is complete, he can get back to testing out the code for developer releases.

ST Binary Releases

Heather asked about the status of releases that would satisfy the likes of David Landriu, which includes gtpython.  Navid feels this is already in place.  The only small trouble is that there is no release that includes a c-shell setup script as well as bash.  However, Navid has made the necessary changes in CVS to include c-shell scripts.

Concerning PYTHONPATH and Chuck's attempts with setting up pyLike. It remained unclear whether there were any additional troubles that were unrelated to the use of the astrotools setup scripts.  PYTHONPATH does not include $ROOTSYS/lib - so that bit is taken care of.

New PyFits

There is a newer release of PyFits 2.1.1, which includes a bug fix requested by David Landriu.  Pending Kim's completion of the installation of python 2.5.1-gl1 on RHEL5-64, we'll consider creating a -gl2, which includes pyfits 2.1.1 as well as any other updates to the extensions we support (numpy,4SuiteXML,pyfits)

ROOT and Mac

ROOT v5.20.00-gl5 was rebuilt on Mac and seems to have fixed the problem with determining dependencies between the ROOT libs.  Richard had heard from Julie that she tried it, and then realized she had to rebuild, which was unsucessful.  Navid asked for a copy of her error messages, which Richard believed he had on ICQ.

Windows

No news as far as getting users to try it out.  Toby is now busy. Tracy is waiting for a version of GR before testing.  And Leon is likely busy with other things.

GlastRelease

Joanne reports there are 30 or so packages remaining that are in need of SConscript files.  She is currently working on G4HadronSim, and has received Tracy's blessing for her updates. To move along we need a few things:

Reorganized OBF  - We seem to be agreed that we can't take OBF as is from FSW, and that a strict use of one-level include/lib directories will not work either.  Instead, we'll likely settle on a hybrid, where most of the files are stored in one-level, but where there are conflicts we will have to provide a deeper directory structure.  Joanne is taking this on.

Build of new Gaudi for VC90 as well as all OSes.  Heather has started, needs to get back to it.

Build of G4 (possibly a later version) for VC90.  Tracy agreed to take a peek.

ASP and RSP

Joanne is plugging away on ASP, no roadblocks yet, but plenty to do.  As for RSP, it depends on both ASP and Scitools and Joanne proposes that before worrying about SCons, that the design of RSP be looked at and simplified.

SCons bootstrap

Joanne explained the thinking behind Tom's work to automate the determination of the path to set up the environment based on the type of OS desired for a run.  It is desired to automate this setup, to prepare the a path to the setup script suitable for the desired combination of variant, debug/opt,etc.  Joanne feels providing a central utility is the way to go.  Navid is willing to help out.  Tom has created a python script as a starting point:

[begin TG update, 9/22/2009]

  • Script is currently stored here: /u/ec/dragon/bin/svs.py
  • Various SCons-related strings can be constructed
  • Lots of parameter overrides so that one may 'force' a particular SCons config independent of the machine being used.
  • Acts as a stand-alone python app, or a python function - both return a single string
  • Currently limited to ScienceTools builds
  • built-in help:
$ /u/ec/dragon/bin/svs.py -h
usage: svs.py [options]

SCons architecture variant string generator

options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -s, --SConsArch       Return SCons architecture variant string
  -c, --SConsComp       Return SCons compiler string
  -i, --SConsInstDir    Return SCons installation directory path
  -b, --SConsBinDir     Return SCons binaries directory path
  -o, --cmtArch         Return cmt architecture string
  -V SCITOOLSVER, --SciToolsVer=SCITOOLSVER
                        Version of ScienceTools to use, default=09-15-03
  -B BUILDTYPE, --BuildType=BUILDTYPE
                        Type of ScienceTools build to use, default=Optimized
  -C COMPILERVERSION, --CompilerVersion=COMPILERVERSION
                        Compiler version desired (e.g., gcc32, gcc34, gcc41)
  -W WORDSIZE, --WordSize=WORDSIZE
                        Machine address length override (e.g., 32 or 64)
  -O OSVERSION, --OSversion=OSVERSION
                        Machine OS version override (e.g., RHEL3, RHEL4 or
                        RHEL5)
  • Example: to construct the path to ScienceTools bin directory: 
    (Tue 11:22) dragon@comet $ svs.py -b
/nfs/farm/g/glast/u35/ReleaseManagerBuild/redhat5-i686-32bit-gcc41/Optimized/ScienceTools/09-15-03/bin/redhat5-i686-32bit-gcc41-Optimized/
    (Note this command was executed from a RHEL5-32 machine)
  • Example: construct a path to ScienceTools bin directory with various overrides: 
    (Tue 11:24) dragon@comet $ svs.py -b -V 09-15-04 -O RHEL3
/nfs/farm/g/glast/u35/ReleaseManagerBuild/redhat3-i686-32bit-gcc32/Optimized/ScienceTools/09-15-04/bin/redhat3-i686-32bit-gcc32-Optimized/
  • Example: return only the SCons architecture variant string 
    (Tue 11:25) dragon@comet $ svs.py -s
redhat5-i686-32bit-gcc41
  • Example: how to use svs.py to set up one's environment to run ScienceTools.
    • Add this to your .bashrc (SCons does not provide a C-shell setup script for ScienceTools 09-15-03 so one is obligated to use bash) 
      export SCONS_ARCH=`/u/ec/dragon/bin/svs.py -s`
export SCONS_BIN=`/u/ec/dragon/bin/svs.py -b`
export INST_DIR=`/u/ec/dragon/bin/svs.py -i`
export GLAST_EXT=/afs/slac/g/glast/ground/GLAST_EXT/${SCONS_ARCH}
    • When ready to run ScienceTools, run the official setup script (either manually or put this into .bashrc after the above lines) 
      source $SCONS_BIN/_setup.sh

[end of TG update]

Tom also noted that the different directory structures in the old-style GLAST_EXT for CMT externals and the SCons version causes some trouble when attempting to set up for both ST and GR.  We could provide symlinks across the board for the GR externals to standardize the setup.  This will probably also be taken care of as we move to support GR SCons builds.

  • No labels