• Release Manager
    • Binary releases for ST
      **
    • Automated builds on our support platforms:  rhel4, rhel4-64, rhel5, mac (for ST), windows
      automated release builds for Windows need to be enabled
    • Enable automated Mac builds for ST at least for now
    • Doxygen generation
    • Generation of calibration and geometry files
  • Release Manager Web Page
    http://glast-ground.slac.stanford.edu/rm2
    Test version is here: 
     http://glast-tomcat03.slac.stanford.edu:8080/rm2/
    • Links to checkout and compile output are not available in the released version of RM2
  • RMViewer
    Stand alone application to view Release Manager builds
  • Developer Needs
    • Ability to override packages for builds
    • Support for containers like celestialSources
    • Obtain source code distributions
    • Obtain developer installs
    • Tag collecting for ease in maintaining container packages
    • Tool(s) for tagging according to our new tagging convention
    • Provide mechanism for container maintainers to tag externals.scons for HEAD and releases
    • Ability to view build results with compilation details available
  • End-User Needs
    • User Installation
      • ability to obtain our binaries as wel as externals
    • Environment set up to run applications with and without python
  • Installer
    • Web based installer
      Test version of web based installer here:  http://glast-tomcat03.slac.stanford.edu:8080/SConsInstaller/
      • There are a few remaining known issues
        a) It would help a lot if we could add a new column to the os table in MySQL which listed the OsType, (for example Windows, MAC OS X, Linux) and OsVariant (32/64). I want to show users only the releases which are compatible with the machine they are running the installer on but it is hard at the moment without building in a lot of assumptions concerning mapping osName to osType.
        b) The Java installer tries to not reinstall files if they are already installed. There are a number of issues which make this hard with the new scons files. First the mapping between downloaded file name and unpacked name is not always consistent. For example:
        ScienceTools is unpacked into ScienceTools-09-11-00/
        Ape (and other externals) unpack into ape/2.3-gl1/
        In addition the 64/32 bit and debug/optimized files are difficult to tell apart because they only differ far down the install path. If it was possible to  add some consistent tag file to all of the zip/tar files that would make things easier? Would it be possible for example for all zip/tar files to contain a
        <package>/<version>/<variant>/<os>.tag
    • Command line installer
    • User Installation
      Available via web based installer and RMViewer
    • Developer Installation
    • Source code distribution
  • GoGui - SCons GUI
  • Command line tagger (stag)
  • Migration to new tagging convention
    • Ability for new/old RM to apply old style tags when we begin using the new tagging convention
  • Windows support (Visual Studio 2008)
    • Obtain / Compile externals as necessary for windows
    • Support for Visual Studio projects
    • Ability to use debugger
    • Support for ROOT package builds
  • Science Tools specific
    • setup of environment for ASP
    • setup of environment for offline analysis
    • Handle f2c requirements on RHEL5 by making f2c an external for now
  • GlastRelease specific
  • CHS specific
    • Migrate CHS packages to SCons
    • (FOS) uses the CHS checkout package to build relocatable RPM's that we install in SLAC AFS space for our various software "platforms".  We use glastpack.pl to extract a suitable source tree from offline CVS, and then build with CMT.  This process needs to use SCons.
    • We rely on the RM HEAD and release build processing to perform the regression tests on the event-decoding software portions of CHS.  However, to my knowledge there are no customers of the RM-created CHS build directory hierarchies in NFS
  •  
  • No labels