SLAC	PEP-II
BABAR
SLAC<->RAL

HEPIC	E,S & H	Databases	PDG	HEP preprints
Organization	Detector	Computing	Physics	Documentation
Personnel	Glossary	Sitemap	Search	Hypernews

Updating a Test Release

When you create you test release with newrel you specify the base release upon which it is based. This release is then used in the search path for include files, libraries and binaries. At some point you may wish to base your work on a more recent release, to take advantage of developments in packages without the need to addpkg them and compile your own libraries. From release 4.2.1 onwards this can be done with the updrel command. To do this cd to your release directory and type

updrel $<$new release$>$

where <new release>is the name of the release that you wish to update to. Updrel updates all CVS checked-out directories created by addpkg, updates all links if this folder was created by GNUmakefile, and cleans up bin/lib/tmp.

Useful Tips, Tricks and Gotcha's

Most of this information is taken from the SRT reference sheet maintained by Torre Wenaus accessible from the Computing/Simulation web page.

Do not move files around between different directories. Specifically if you have more than one copy of PackageA checked out (from different releases), do not copy files between the two. People often do this when working in more than one place and they want to copy a file from release X that they have modified at one site/computer/directory to a second site/computer/directory where they have PackageA from release X+1 checked out. Problems arise when they commit the code from the second site/computer. In checking for changes, CVS will compare the users file with the tagged version of PackageA corresponding to release X+1. However, the modified file originally came from release X. Any changes implemented between releases X and X+1 will be missing from the users copy. CVS will assume that these ommissions are intentional edits by the user and unless they conflict with other changes CVS will not complain. Thus, when the file is commited the changes from version X+1 will be ``mysteriously'' removed in the new version.
The current archive location is $BFROOT/dist/releases/current/ and specific releases are found in eg. $BFROOT/dist/releases/0.5.5
Be aware that the version of SRT commands that you are using is determined entirely by BFCURRENT which is 'current' unless you have a $HOME/BFCURRENT file. Thus if you make a 0.7.1 area with newrel, but 'current' is still 0.6.2, when you use SRT commands such as 'addpkg' in your new area, you will be using the old 0.6.2 version. To pick up a version associated with 0.7.1, you either have to set $HOME/BFCURRENT or do 'addpkg SoftRelTools ; gmake SoftRelTools.bin'.
The following directories are prepended to PATH:
```
  ./bin/$BFARCH
 $BFDIST/releases/$BFCURRENT/bin/$BFARCH
```
BEWARE of these! Note that they go on the FRONT of your path. Also if you are trying to run something that should be in ./bin/$BFARCH but is not, it will be pulled from $BFDIST/releases/$BFCURRENT/bin/$BFARCH, and won't reflect any personal mods you've made to the program. It could even be the wrong version if $BFCURRENT is different from the version you specified with 'newrel'.
Include statements should be of form: #include "packagename/file.h". The 'addpkg' command creates a link include/packagename to the first of the following it finds in a package directory:
- A subdirectory with the same name as the package
- A subdirectory named "include"
- The package directory itself
(NOTE that only the first of these is recommended, the others are to support older packages and may be removed in time)
The directories searched for #included files are: (in order)

1.

tmp/$BFARCH

2.

$BFDIST/releases/$BFCURRENT/tmp/$BFARCH

3.

include (addpkg creates a link 'packagename' in this directory pointing to the package directoty itself, this way include files can easily be traced)

4.

$BFDIST/releases/$BFCURRENT/include
Key commands include:
- newrel <option> current <pick-a-name>
  Create your own (empty) release system directory pick-a-name. Options include:
  
  -t
  
  generate empty test release in user's directory
  
  -p
  
  generate production release. Issue only from $BFDIST/releases.
  
  Requires a base release number as a parameter, to use as a model.
- addpkg <option> <package name> [<version>]
  Add package (eg. gnbase) to your release directory. Issue from your release directory. Optionally, package version can be specified. Also does a 'gmake installdirs' to set up dirs for the package. Options include:
  
  -R
  
  passed to CVS to control RCVS. Needed at remote sites.
  
  -h
  
  get the most recent version (from the Head of the repository)
- gmake <option>
  Set up directories and build the release. Options include:
  
  clean
  
  Tidy everything up, remove existing libraries, binaries and start again.
  
  include
  
  Set the appropriate links to ensure that the include files for all your checked out packages can be accessed via the include directory. Also builds any include files which are auto-generated by the package.
  
  lib
  
  Create the libraries for all your checked out packages (must be done after the inlcude step).
  
  bin
  
  Create the binaries, if any, for all your checked out packages (must be done after the lib step).
  
  all
  
  Do all the above steps in order for all your checked out packages .
  
  test
  
  Run any standard tests provided your checked out packages (must be done after the bin step).
  
  -s
  
  suppress error messages
  
  -no-p
  
  suppress the messages for ``entering'' and ``leaving'' directories
  
  <package.phase>
  
  request that gmake only process one package directory and one phase, for example, `gmake gnemca.lib` to remake only the calorimeter simulation library. The ``phases'' are ``include'', ``lib'', ``bin'' and ``all'' (Which is equivalent to doing all the other three).
  
  VERBOSE=yes
  
  Turn on debugging messages during gmake (includes printing out all the commands as they are executed)
COmpiler options can be passed to gmake by setting the following environment variables:

CCFLAGS

for C code

CXXFLAGS

for C++ code

CPPFLAGS

for C preprocessor

FCFLAGS

for FORTRAN code

These may be passed as arguments to gmake, e.g. :
```
gmake [...] xxxFLAGS=-g
```
Select the preferred compiler via the following environment variables:

CC

for C compiler (default is `cc`)

CXX

for C++ compiler (default is the vendor C++ compiler for the given platform)

FC

for FORTRAN compiler (default is `f77`)

Note that the same C++ compiler must be used for all C++ compilations (the B A B A R releases and you own) to avoid problems with name mangling conventions.
gmake, determines what files need to be compiled via dependencies which are kept in ``.d'' files in tmp/<packagename>.
Be sure you obtain packages with 'addpkg' and not 'cvs co'. If you do the latter out of habit, you'll have trouble (eg. the make procedure unable to find the package include files). To recover from having used 'cvs co', just use addpkg, even though the directory already exists.
If you find yourself unable to do a commit on a package file because of a sticky bit error ('sticky tag not a branch'), do 'cvs update -A' first. '-A' resets any sticky tags.
If you encounter gmake attempting compilation with a bad rule, this may be due to 'bad craziness in the .d file'. Delete the file tmp/$BFARCH/package/name.d and try again.
If you are getting 'can't find include file' errors when trying to compile a package, the reason is often bad .d files. Do 'rm tmp/$BFARCH/package/*.d ; gmake package.include' and try again. Other possibilities:
- you're not in your release directory (created by newrel)
- there's no link in include/ for the package, in which case do 'addpkg name'
- the included file in the code is not in the form #include "package/file.h"
- the includes are kept in a place where addpkg can't find them (see addpkg search procedure above)
If you change BFCURRENT by editing the file $HOME/BFCURRENT (the only sure way to change it), then you must rerun the dreaded SRTstartup.sh, otherwise the PATH and MANPATH are wrong.
Be sure your login scripts do not print stuff to the screen. This can cause rCVS (used by addpkg) to fail, often with a 'mismatched version numbers' error.
When you do a 'cvs update', any files that are changed have their timestamps set to the time of the original committed change, not to the time of the update. This can be a problem for gmake. Even if the contents of the file were changed, the file's timestamp can still be older than the library member(s) made from it. When this happens, gmake does not know to rebuild anything. One way to avoid this is to always "gmake clean" after an update. Carefully applying the touch command to every file that CVS mentions can do it too, although its error-prone.

Next: Some Simple Rules for Up: Using SRT Previous: Putting your changes back

Neil I. Geddes
1998-11-18