 
Next: Putting your changes back Up: The B A B
Previous: Bug Reporting
Using SRT
The following sections give some advice on how to actually develop software in the B A B A R SRT+CVS environment. Most of the following sections are also
likely to be of interest to ``users'' as well as ``developers''. A working knowledge of the B A B A R file organisation is assumed and readers should refer to sections 3.3 and 3.2. For up to date detailed information about how to use and not use SRT,
including information on creating your own GNUmakefiles and how to make local modifications, refer to the SRT ``How To'' pager. For more background on SRT and what specific
commands might do, refer to the SRT documentation:
$BFROOT/dist/releases/current/SoftRelTools/*.ps
Examples of other common tasks and programs can be found in the individual program chapters.
The basic principle behind SRT, from a users point of view, is that users create their own, private, releases; similar to those found under $BFROOT/dist/releases . In the users case, however, a release is
typically a very lightweight collection of directories and is tied to a full B A B A R release. With the initialisation and creation of a users release comes a GNUmakefile which ``knows''
where to look for binaries, libraries and include files of the official B A B A R release. To initialise the SRT system the user must type:
source $BFROOT/dist/releases/current/SoftRelTools/SRTstartup.csh
if using the c-shell (csh), or
. $BFROOT/dist/releases/current/SoftRelTools/SRTstartup.sh
if using the bourne (sh) or korn (ksh) shells.
This startup script defines the following environment variables:
BFDIST set to $BFROOT/dist
BFARCH set to operating system name (actual form depends upon system)
BFCURRENT set to "current", the default full release to use
If you want to use a release other than ``current'' then create a $HOME/BFCURRENT file containing a single line with the desired release number. This will override the default setting for
BFCURRENT after you next source SRTstartup. The default PATH and MANPATH are also extended to include the binary and man directories for the default release:
$BFROOT/dist/releases/$BFCURRENT/bin/$BFARCH and
$BFROOT/dist/releases/$BFCURRENT/man
These paths are also extended to include
./bin/$BFARCH and
./man
which become important when you are working in you private release directory. These last additions go at the front of the PATH so that your own release will override the default B A B
A R files.
The extension of PATH gives you access to the SRT commands and the ``current'' versions of other B A B A R binaries. The extension of the MANPATH gives
access to the man pages for B A B A R commands such as those used below (newrel etc.). Next create your own release:
newrel -t current myrel
This will create a release directory called myrel in your current directory, based upon the current official release; i.e. by default when using `gmake` to compile files in myrel, appropriate include and
lib directories in
$BFROOT/dist/releases/current
will be searched.
To tie your own release to a B A B A R release other that current then simply modify the -t option appropriately, e.g.
newrel -t 0.8.0 my080
Your new release directory myrel will contain several empty directories (bin, doc, include, lib, man, results and tmp) and a GNUmakefile. The GNUmakefile is the master one for B
A B A R software. It is this make file which ``knows'' where all the libraries and include files are. The following sections show how to use this private release directory. Although the following examples use
the gnbase (bbsim) and gnemca packages, any package can be installed in your release. SoftRelTools (SRT) is itself package. It is also possible to add packages which have not yet been released (have no directory in $BFROOT/dist/packages) as long as they
are in the CVS repository. Finally you can create you own packages.
Run bbsim
cd myrel
addpkg gnbase
bbsim
The `addpkg` command, checks out the gnbase package from the your CVS repository. The version of the package you get is the tagged version corresponding to the release with which you originally
created myrel. The gnbase package contains the input files and scripts required to run bbsim. `bbsim` is a script in the gnbase package which controls execution of the bbsim program itself; Refer to the bbsim documentation on the web
(BaBar/Computing/Simulation/) for further details. The manual page for the bbsim script itself can be read via `man bbsim` after initialising SRT.
If you addpkg a package which already exists in your release, then addpkg will, after confirmation by the user, update the package directory to the version appropriate for the release and will then check that the
required links (in the include directory) are present.
cd myrel
addpkg gnbase
addpkg gnemca
Now you can modify the code in (your private copy of) gnemca. Again the version of the emca package that you get will be that corresponding to your release. If you want another specific package version then include this
version number when adding the package:
addpkg gnemca V00-01-99
You can also ask for the code corresponding to the current head version in CVS:
addpkg -h gnemca
After making your modifications you should (re)make your own copy of the bbsim executable:
gmake
Gmake will, by default, make all the binaries and libraries associated with any packages which you have checked out (addpkd'd) into your release. You should issue the command from your release directory. The rules contained
in the GNUmakefile will ensure that any libraries required from the B A B A R release will be found.
Once you have packages checked out in your release. These packaes take preference over the copies in the B A B A R release. Thus you can check out
packages and modify code/headers and any subsequent gmake will pick up your modified code/libraries in preference to the B A B A R default versions.
   
Next: Putting your changes back Up: The B A B
Previous: Bug Reporting
Neil I. Geddes
1998-11-18
|
