This new package is a container package, which lists explicitly
every package/version that are required to build Gleam, as well as packages
needed by other applications based on Gleam, e.g. GRB. Each tag of this
package defines a new release. On a lower level, we identify versions building
up to a release by the revision number of each GlastRelease requirements file.
If you look at Alex's build system page, this is clearly shown by the
builds page:
A very important feature of the build system is that every night it tries
to build a potential GlastRelease based on the most current tagged versions of
all the packages specified in the requirements file. This allows provisional
"builds" without commitments by developers. We defined the latest version v1r0
by simply promoting all of these packages, when all compiled and ran their
integrated tests OK.
Currently developers must request new packages, or new revisions of current
packages, by sending e-mail to the core group with "GlastRelease tag request"
in the subject line. Alex uses these to update the GlastRelease requirements
file. It is planned to have a web request form for this purpose.
Tools
We use Gaudi tools heavily, and under GlastRelease, we have a policy that
tools must be set up only in the initialize() method. This is to
allow services like GlastRandomSvc, GuiSvc, and FluxSvc to search for
special tools implementing interfaces allowing access to features specific
to one of the above. That is, all tools must expect to be instantiated
(constructor run) and immediately deleted with no secondary affects.
The new set of tools under the package
AnalysisNtuple, authored by Leon, satisfy this requirement, and are a
good example of how to define a set of tools all implementing a common
interface.
Windows startup
When a Gaudi application starts executing, it first runs normal
initialization code, then jumps to:
-
main if the application was not build with GuiMain.
-
Winmain otherwise. In this case, after the windows setup, control
passes on to main.
These options are controlled by the packages GlastPolicy and GuiSvc.
We created a new
"container" package,
IExternal,
to contain the interface packages. It currently contains all the external
packages needed by Gaudi v11r4, and our interface to Gaudi itself. Since it is a
container, the CMTPATH needs only to point to the folder containing the
package, so if it is in the same folder as GlastRelease, nothing more has to be done
to expose its packages, which must be used with the requirements file
statement
use ROOT v2* IExternal
for example. The contained packages are also under IExternal in
cvs, and so are new copies of some, like ROOT. One checks out the lot with the
cmt command,
cmt co -R IExternal
but note that IExternal cannot already exist. Since it is
included in GlastRelease, this is usually not necessary.
There is a little gotcha associated with tagging IExternal. One should
never tag IExternal itself, since that applies the same tag to all the
contained packages. [ATLAS has a better system.] Instead the tag has to be
applied specifically to the relevant folders under IExternal, namely IExternal/cmt
and IExternal/doc. Tagging an external package is fine, the cvs path is
of course IExternal/package.
The following table has a list of the packages contained by IExternal, and the
reference paths on Windows (glast-ts) or Linux (SLAC)
| Interface Package, in IExternal |
native
version |
Path to libs/includes |
| Name |
Version |
Windows |
Linux |
| AIDA |
v3r221p0 |
2.2.1 |
AIDA/2.2.1 |
AIDA/2.2.1 |
| CLHEP |
v2r1800p1 |
1.8.0.0 |
CLHEP/1.8.0.0 |
CLHEP/1.8.0.0 |
| HTL |
v2r1311p1 |
1.3.1.1 |
HTL/1.3.1.1 |
HTL/1.3.2.1 |
| ROOT |
v2r30402p0 |
v3.04.02 |
ROOT/v3.04.02 |
ROOT/v3.04.02 |
| Geant4Runtime |
v2r50p0 |
5.0 |
geant4/5.0 |
geant4/5.0 |
| XMLEXT |
v3r152p2 |
c1_5_2 |
xerces-c1_5_2-win32 |
xerces/1.5.2 |
| cfitsio |
v1r2410p0 |
v2410 |
cfitsio_v2410 |
cfitsio/v2410 |
| GaudiInterface |
v0r114p0 |
v11r4 |
gaudi/v11r4 |
gaudi/v11r4 |
| MYSQLEXT |
v0r32349p0 |
3.23.49 |
mysql/3.23.49 |
mysql/3.23.49 |
Gaudi
This is now external, but organized as CMT packages as
before. We put them under $GLAST_EXT/gaudi/v11r4. The binaries are in the
usual place for CMT packages, $CMTCONFIG folders in each package. This is
explicit in the interface package
GaudiInterface. This is a new package contained by IExternal,
with the minimal interface to access all of the separate binaries and includes
in Gaudi. For now, it is pretty simple, with includes to GaudiKernel, and
binaries for GaudiSvc, GaudiTools, GaudiAlg, GaudiAud, and RootCnvSvc.
Glast packages using Gaudi facilities need only the statement
use GaudiInterface * IExternal
It is built with the same external policy and external interface packages as
the rest of Glast software. The CMT path must then have the following
components to build it: $CMTCONFIG/gaudi/v11r4 of course,
and the folder IExternal itself. The latter gives the Gaudi requirements files
direct access to the interface packages.
A problem is that stepping into these packages is a bit more difficult
than it used to be. We do not have a very well defined system for building
new gaudi releases, or maintaining the differences between our version and
the Gaudi release.
Geant4
In addition to converting to version 5.0, we now build it for windows
using a very nice package developed by Tracy Usher, called
Geant4build. By default, it depends on Geant4Runtime, for paths to the
source, and for the path to place binaries. This allows us to specify
specific build parameters, and especially it is the only way to build
under vc7. An unfortunate consequence at the moment is that the zip file is
very large. See
ftp://ftp-glast.slac.stanford.edu/glast.u05/extlib/geant4.
Root
We have switched to v3.04.02. A change is that now the version string
starts with "v". A problem is that we cannot use vc7 to build packages that
depend on root, since the ROOT folks do not distribute binaries built with
vc7. Since the ROOT distribution has flaws for Windows, Heather has
modified it for us. [But not installed on the TS.]
MySQL
This is a new external package, required by the calibration system. It is
maintained by Joanne.
vcmt (after v16) now only uses the "cmt co" command for cvs checkout of
packages. It provides for recursive checkout. The checkout dialog box
has a checkbox for this possibility. (The "add" button behaves as before, and
is useful for checking out dependent packages.) A bit gotcha with cmt co is
that it will fail if the package already exists in a folder with the most
recent tag. On THB's TODO list to work around.
vsnet
There is support for Visual Studio .Net, with the new C++ compiler vc7,
in vcmt and our special version of CMT. [Here
is a link to info on that.] This functions pretty much transparently, but
there are some glitches that only heavy usage will expose and get ironed
out. Currently, only Tracy is able to use it, since he has a solution
to the root problem. Thus it is on THB's TODO list to make the standard vc6,
instead of vc7 if it is available, the default option from vcmt. [Joanne,
please mark that.]
Linux version
The Linux version has also been fixed to allow recursive checkout.
The SLAC version of glastpack [Feb 6 20:28 /afs/slac.stanford.edu/g/glast/ground/scripts/glastpack.pl]
provides the following help:
usage: glastpack.pl create dirname
usage: glastpack.pl help command
usage: glastpack.pl build version
usage: glastpack.pl rco package version
usage: glastpack.pl run package exename <arguments>
usage: glastpack.pl add /path/to/area
usage: glastpack.pl rebuild package
usage: glastpack.pl remove /path/to/area
usage: glastpack.pl co package version
usage: glastpack.pl login
usage: glastpack.pl logout
The rco command is new, to allow for recursive checkout, as
explained in this
email from Alex.