 
Next: Development Software and CVS Up: B A B A
Previous: B A B A
Subsections
B A B A R Software Release Structure
The bulk of B A B A R specific software is organised and maintained in a single, self
consistent, file system under $BFROOT/dist (for distribution). The basic unit of software is referred to as a package; with many packages being combined into releases. The whole release system is often referred to as SRT, referring to the
SoftRelTools (Software Release Tools) package which is itself used to install and maintain releases.
Packages
B A B A R (reconstruction and simulation) software is organised in terms of ``packages''. A package is a self contained piece of software intended to perform a well defined
task, e.g. find calorimeter clusters, simulate the drift chamber response. Each package has a unique name and its own library and include files. Some packages may not be usable on their own, requiring integration with others, for example the individual
subsystem simulation packages which together form the Geant simulation of BaBar.
Packages are maintained by a package coordinator, who is responsible for testing the code and releasing new versions when appropriate. The source code (plus documentation etc.) for stable, self consistent versions of all packages are
found in their own subtrees under $BFROOT/dist/packages. Within each package subtree, there may be one or more ``versions''. This allows the package coordinator to ``publish'' code as needed and leaves the issues of naming, timing and quality
control up to the relevant experts. All the files required for the package should then be contained within the single package directory which will also include a GNUmakefile which implements some standard targets and definitions. Older packages may not
conform to this rule and for these there may be a hierarchy of subdirectories within the package directory itself. In these cases all ``externally visible'' include files will be found in one of the following standard places:
- a subdirectory with the same as the package, or
- a subdirectory named include
Numerous problems with compilers and debuggers have meant that these freedoms are no longer recommended and all new packages should put everything in a single package (version) directory.
At the time of writing the list of packages in the Software Release tree, corresponding to the list of subdirectories under $BFROOT/dist/packages, is:
AbsEnv EmcData SvtData gelhad gnssvd
AbsEvent EmcReco SvtReco gismo gntrol
AbsTrack FrameExample abse.Z gnaero gnunt
Aslund Framework beget gnbase gnutil
AtcData G3Data colias gnbbg gweed
BaBar G4Geom dbin gnbpip jetset
BbrGeom HepTuple dbinPlain gndcha klmn_ryd
CERNLIB IfrData dbio gndirc koralb
CLHEP McTrkr euclid gnemca mcfio
DbiEvent MicroFrame farfalla gnfttk stdhep
DchData RecoUtils geane gnmisc unt
DrcData SoftRelTools geant gnmuon workdir
The Framework package, for example, then has the following subdirectories
V00-01-01 V00-03-01 V00-03-03
and each version directory contains further subdirectories for the source code, include files and documentation:
Framework/ GNUmakefile README doc/ src/
Note that there are no binary (executable or library) files in this tree. Also the source code is there as a reference copy for the given version and should not be modified. The actual development code, from which the reference
copies are taken is maintained using the CVS package which is detailed below.
Creating New Packages
Developers who wish to create new packages should do so by submitting a request to the Tools Group using the web form at http://hepunx.rl.ac.uk/BFROOT/doc/Computing/www/Tools/ToolsHome.html. This form has several questions and reminders relating to the contents of the proposed
package. The request will be considered by the Tools group, who may suggest modification to the contents if appropriate (e.g. Dont store binary files). An approved package consists of a cvs module for revision control, a package directory in
$BFROOT/dist/packages, a gnats problem tracking group, and one or more package coordinators. After a package has been initialized, it is elegible for inclusion into the BABAR Software Release Structure and become part of an official software release after
approval by the release coordinator. Package coordinators are strongly urged to monitor the BABAR Software Admin web site for up-to-date instructions and suggestions for their role.
Releases
A software ``release'' consists of a consistent set of packages together with the libraries and binaries created for various machine architectures. Within the $BFROOT/dist/releases subtree there is a subdirectory for each existing
release. These are typically names with simply a number, e.g. $BFROOT/dist/releases/0.7.1/ will contain all the binaries and libraries for release 0.7.1. The release also contains pointers to the reference versions of the packages (implemented using UNIX
links to the relevant package subdirectories). The release coordinator can create releases of various quality levels as required. Given releases may then be retained for as long as required. Links within the releases directory can be used to
provide useful default names for particular releases, for example, current for the release recommended for general use at the present time.
Once this dist tree has been installed on a users machine, the source code, libraries and binaries of any particular versions can be directly accessed through the releases tree. The user can then stay with a particular
release until it is appropriate to move to a newer one. In the meantime, package coordinators can be creating new versions of their code and integrating them into releases entirely asynchronously.
The $BFROOT/dist/release tree currently has the following subdirectories (when you read this, the exact listings wil be very outdated !)
drwxr-xr-x 4 bfactory bfactory 512 Jul 20 17:53 0.3.7
drwxr-xr-x 4 bfactory bfactory 512 Jul 20 17:53 0.3.8
drwxr-xr-x 4 bfactory bfactory 512 Jul 20 17:53 0.4.2
drwxr-xr-x 4 bfactory bfactory 512 Jul 21 17:53 current -> 0.3.8
drwxr-xr-x 4 bfactory bfactory 512 Jul 21 17:53 test -> 0.4.2
At the time of writing (now long out of date !) there are 3 releases, numbered 0.3.7, 0.3.8 and 0.4.2. Release 0.3.8 is the ``current'' release as indicated by the symbolic link. The current release should be the default choice for
users. It represents the most recent stable release. Release 0.3.7 is an old release which is still being used and version 0.4.2 is a new test release. After a period of testing, if found to be stable and reliable, this release may well become the
"current" release. Release 0.4.0 and 0.4.1 have presumably been deleted and never made it to ``current'' due to various bugs andfeatures. Looking more closely at the subdirectory 0.3.8:
lrwxrwxrwx 1 bfactory bfactory 30 Jul 4 19:12 BaBar ->
../../packages/BaBar/V00-00-02
lrwxrwxrwx 1 bfactory bfactory 28 Jul 4 19:12 CLHEP ->
../../packages/CLHEP/V0-13-5
lrwxrwxrwx 1 bfactory bfactory 37 Jul 4 19:12 FrameExample ->
../../packages/FrameExample/V00-00-02
lrwxrwxrwx 1 bfactory bfactory 34 Jul 4 19:12 Framework ->
../../packages/Framework/V00-00-03
-r--r--r-- 1 bfactory bfactory 4177 Jul 3 06:42 GNUmakefile
lrwxrwxrwx 1 bfactory bfactory 33 Jul 4 19:12 HepTuple ->
../../packages/HepTuple/V00-01-03
-rw-r--r-- 1 bfactory bfactory 5037 Jul 3 06:41 ReleaseLog
lrwxrwxrwx 1 bfactory bfactory 37 Jul 4 19:12 SoftRelTools ->
../../packages/SoftRelTools/V00-01-27
lrwxrwxrwx 1 bfactory bfactory 30 Jul 4 19:12 beget ->
../../packages/beget/V00-21-04
drwxr-xr-x 4 bfactory bfactory 512 Jul 21 17:53 bin
lrwxrwxrwx 1 bfactory bfactory 31 Jul 4 19:12 colias ->
../../packages/colias/V00-01-11
lrwxrwxrwx 1 bfactory bfactory 29 Jul 4 19:12 dbin ->
../../packages/dbin/V00-02-00
drwxr-xr-x 2 bfactory bfactory 512 Aug 25 03:05 doc
lrwxrwxrwx 1 bfactory bfactory 31 Jul 4 19:12 euclid ->
../../packages/euclid/V00-02-00
lrwxrwxrwx 1 bfactory bfactory 33 Jul 4 19:12 farfalla ->
../../packages/farfalla/V00-17-04
lrwxrwxrwx 1 bfactory bfactory 30 Jul 4 19:12 geane ->
../../packages/geane/V00-02-00
lrwxrwxrwx 1 bfactory bfactory 30 Jul 4 19:12 geant ->
../../packages/geant/V03-21-02
lrwxrwxrwx 1 bfactory bfactory 31 Jul 4 19:12 gnaero ->
../../packages/gnaero/V00-02-00
drwxr-xr-x 4 bfactory bfactory 1024 Jul 3 07:20 gnbase
lrwxrwxrwx 1 bfactory bfactory 30 Jul 4 19:12 gnbbg ->
../../packages/gnbbg/V00-02-00
lrwxrwxrwx 1 bfactory bfactory 31 Jul 4 19:12 gnbpip ->
../../packages/gnbpip/V00-02-00
...
each of the packages is included in the release via a symbolic link to the relevant subdirectory in the packages tree (i.e. $BFROOT/dist/packages). The
include directory similarly contains links the include files for the packages. The bin and lib subdirectories contain further, architecture specific directories, which in turn contain the binaries and libraries for that release.
For example
bin/:
total 20
drwxr-xr-x 2 jake 512 Jul 2 23:23 AIX2
drwxr-xr-x 2 jake 512 Jul 3 07:15 HP-UXA
drwxr-xr-x 2 jake 512 Jul 3 07:24 OSF1V3
drwxr-xr-x 2 jake 512 Aug 8 00:34 SunOS4
drwxr-xr-x 2 jake 512 Jul 3 02:08 SunOS5
bin/HP-UXA:
total 9600
-r-xr-xr-x 1 bfactory bfactory 2266 Jul 17 17:22 addpkg
-r-xr-xr-x 1 bfactory bfactory 4161 Jul 17 17:22 auditrel
-r-xr-xr-x 1 bfactory bfactory 2009 Jul 17 17:22 auditver
-rwxr-xr-x 1 bfactory bfactory 407 Jul 17 17:24 bbsim
-rwxr-xr-x 1 bfactory bfactory 458 Jul 17 17:24 bbsimb
-rwxr-xr-x 1 bfactory bfactory 1019 Jul 17 17:24 bbsimb20
-rwxr-xr-x 1 bfactory bfactory 656752 Jul 17 17:22 cTest
-rwxr-xr-x 1 bfactory bfactory 648560 Jul 17 17:23 cTestRead
-rwxr-xr-x 1 bfactory bfactory 106772 Jul 17 17:24 dbin
-r-xr-xr-x 1 bfactory bfactory 10927 Jul 17 17:22 f77bb
-r-xr-xr-x 1 bfactory bfactory 209 Jul 17 17:22 fix_gnbase
-r-xr-xr-x 1 bfactory bfactory 2134 Jul 17 17:22 freezerel
-rwxr-xr-x 1 bfactory bfactory 950328 Jul 17 17:24 gnbabar
-r-xr-xr-x 1 bfactory bfactory 1873 Jul 17 17:22 importarch
-r-xr-xr-x 1 bfactory bfactory 2455 Jul 17 17:22 importrel
-r-xr-xr-x 1 bfactory bfactory 2028 Jul 17 17:22 importver
-r-xr-xr-x 1 bfactory bfactory 6617 Jul 17 17:22 newrel
-r-xr-xr-x 1 bfactory bfactory 1632 Jul 17 17:22 newver
-r-xr-xr-x 1 bfactory bfactory 1570 Jul 17 17:22 rmrel
-r-xr-xr-x 1 bfactory bfactory 1509 Jul 17 17:22 rmver
etc... for other architectures.
Symbolic Releases
As indicated above, several symbolic links in $BFDIST/releases are used to refer to particular releases. Form release 4.2 onwards these symbolic releases are defined as follows:
- latest
- The most recently built release. The only quality requirement is that thre release (mostly) compiled. The release coordinator (Doug Johnson) determines which release this should point to.
- test
- The most recent release which has passed basic tests, such as running the full reconstruction on a small number of events. The reconstruction coordinator (Bob Jacobsen) determines which release this should point to. Not all latest releases will
become test releases.
- current
- This release is the most recent to have reached an acceptable level of quality. Acceptable is detemined by a combination of code and physics checks as defined by the QA/QC group with input from the physics groups and detector subgoups. The QA/QC group
(Dave Aston) determines which release this should point to.
- prod
- This release is the release currently being used for large scale production. This link is controlled by the production coordinator (Adil Hasan).
Other symbolic release names may be defined as and when required.
   
Next: Development Software and CVS Up: B A B A
Previous: B A B A
Neil I. Geddes
1998-11-18
|
