P = Phase I requirements

  1. download everything with a command
  2. build externals & install
  3. build product & install (P)
  4. chain development release to base release for builds (P)
  5. shared exdternals & base release for all users on the system
  6. clear coupling from the product to a version of an external product
  7. base release establishment (shared area)
  8. development / runtime establishment
  9. offsite install - OS = SL5.x (P), Ubuntu, Debian, Macos
  10. compiler = gcc (P), multiple versions and perhaps different vendors
  11. maintain configure scripts for external products (root, Geant4, boost especially)
  12. install in project space (bluearc) (P)
  13. root access not necessary (P)
  14. light-weight installed runtime environment (no source)
  15. want source redistributed through us (for consistency of download and predictability)
  16. if external product is present in system, then we should use it
  17. bootstrap with /bin/sh so that system independence can be achieved
  18. release management strategy - naming or tagging conventions
  19. convert to cmake (P)

Notes from Rob (adding mu2e requirements)

The general Mu2e software getting started page

The standard example is 5 bullets down:

A possibly useful talk:

Some comments on what I want in a build system. In a number of places below I mention that I like some things about SRT. This is just a short way to specify the functionality that I like.

1) Currently scons does a build in place. I would like to change this for two reasons:
- two builds for one source ( SLF4/SL5, test of new compiler ).
- possiblity to put obj and libs on non-backed up disk and keep source on backed up disk.

SRT can do this.
cmake does this by default, and calls this an out-of-source build

2) Currently:
- Most external packages are under this directory.
- We get G4 from ups/upd
- Either put G4 into MU2E_EXTERNALS or put all in some external products manager, maybe Ron's ups lite.
- Currently misnamed.
- This is really framework home.
- From the Mu2e point of view, the framework should be just another external package.
- Need to be able to build several versions from one source.

3) Right now the concepts of base release and test release do no exist. We need them.

4) The current setup scripts use their own directory name to learn info. We want the ability to run the 32 exe's on a 64 bit platform. Cannot do this with current setup scripts.

5) MU2E_HOME has some stuff left over from Ron's early attempts at setting up examples. Kill it. I guess this is my job.

6) Is this the right place to ask for scripts that make a new module or service from template.hh and .cc files? I view this as coupled with test releases.

7) How does a user install the Mu2e code on their laptop? What about a central cluster at a remote site?