This section discusses how to properly select and checkout a
package. One should:
- completely identify the package of interest
- select a work area
- perform the checkout
1. completely identify the package of interest
To identify a package you must know its name, and the
name if its container(s) if it is a sub-package. As well, the
package tag associated with a given release is needed to check
out a specific version of the package.
Both CMT and the taginfo
tool offer queries to extract this information, or one can
simply look at a release or use the Tag Collector.
(Note: to use
the taginfo command, you need
to have setup your runtime environment as described in [5.1]. For this it is sufficient to
have done the sourcing of the setup in the TestRelease
package:
> cd TestRelease/TestRelease-00-00-14/cmt
> source setup.[c]sh
)
For example, if one wants to find out about the
GeneratorModules package, one can alternately:
> ls /afs/cern.ch/atlas/software/dist/5.2.0/Generators/GeneratorModules [1]
GeneratorModules-01-02-35
...
> taginfo package -name=GeneratorModules [2]
simplePackage;offline/Generators/GeneratorModules/;GeneratorModules;GeneratorModules-01-02-35
> taginfo package -name=GeneratorModules -release=5.0.0 [3]
simplePackage;offline/Generators/GeneratorModules/;GeneratorModules;GeneratorModules-01-02-30
> taginfo package -name=GeneratorModules -release=under_construction [4]
simplePackage;offline/Generators/GeneratorModules/;GeneratorModules;GeneratorModules-01-02-38
> cmt show packages | grep GeneratorModules [5]
GeneratorModules GeneratorModules-01-02-35 /afs/cern.ch/atlas/software/dist/5.2.0/Generators/GeneratorModules
> cmt cvstags Generators/GeneratorModules [6]
GeneratorModules-01-02-38
GeneratorModules-01-02-37
GeneratorModules-01-02-36
...
> taginfo cvstags -name=GeneratorModules -all=1 | cut -d';' -f4 [7]
GeneratorModules-01-02-19
GeneratorModules-01-02-18
GeneratorModules-01-02-17
...
- This lists the version of the package in release 5.2.0
from the cern dist area
- This command shows the GeneratorModules package for the
latest frozen release
- This command shows the GeneratorModules package for
release 5.0.0
- This command shows the GeneratorModules package for
the release currently being worked on
- This command shows all packages reachable from the current CMTPATH list
- This command shows all CVS tags currently applied to this package
- The same query but using taginfo instead
2. select a work area
A work area is a directory where one checks out one or more
packages to work on. When there is more than one package in
a work area, CMT needs to know where this work area
is, so as to include it in the package
search-path-list. This is simply done by installing the work
area in the environment variable CMTPATH.
In the special case of working on only a single package, it
is not required to add one's work area to CMTPATH. In
this case you will be building in the cmt directory of
this package and only the base release is needed and is
already in CMTPATH. Thus for this simple scenario you
may skip the rest of this subsection and checkout your package in
any directory.
To add your work directory to CMTPATH, one may use
the shell commands :
sh> export CMTPATH=${HOME}/MyTest:${CMTPATH}
csh> setenv CMTPATH ${HOME}/MyTest:${CMTPATH}
Or one may use the method via your in the login requirements
file (as described in [3.1.1.2]):
macro home_dir "${HOME}"
path_remove CMTPATH "${home_dir}" [1]
path_prepend CMTPATH "${HOME}/MyTest" [2][3]
- this will first remove from CMTPATH from any
item containing the string "${HOME}" or
your home directory path
- this adds the selected work area at top of the path list
- the order in CMTPATH is relevant,
i.e. one does path_prepend
as opposed to
path_append because
packages are searched for in the the directories of
CMTPATH from left-to-right
After modifying your login requirements file, you must
again source your home setup file:
> source ${HOME}/cmthome/setup.[c]sh
with any tags you may want. See Setting up for sessions
[3.2].
(For more details see how to select a work area)
3. perform the checkout and rebuild the package
One can either check out the HEAD revision or a specific
tagged revision of a package.
For the HEAD revision of a package, one does a
cmt co without any
options:
> cd ${HOME}/MyTest [1]
> cmt co Generators/GeneratorModules [2]
# ================= working on package GeneratorModules version GeneratorModules-01-02-13 (At head) path Generators
# get top files
# get branches GeneratorModules cmt doc src share
# Required version v17r10 of package CLHEP incompatible with selected version CLHEP-00-01-07 [3]
Creating setup scripts. [4]
Creating cleanup scripts. [4]
> cd Generators/GeneratorModules/*/cmt [5]
> gmake [6]
- one must be in the work area directory
- without tag specification, the HEAD revision will be
checked out
- this is a warning and can be ignored
- a cmt config action is automatically executed, so
as to generate the setup scripts for the checked out package
- build operations must be performed from the cmt directory
- we first rebuild this package
To check out a specific tagged revision of a package, one uses
the -r option of the
cmt co command.
Note that in this
case, the checkout operation will produce what CVS calls a
"sticky tag"
which means that in principle no modification is expected to
be checked back in for this
package (i.e. one can only check back in changes for HEAD
revisions of packages, unless the specified tag is a branch
tag). This is typically useful when a previous version of this
package is required.
> taginfo package -name=GeneratorModules -release=3.0.1 [1]
simplePackage;offline/Generators/GeneratorModules/;GeneratorModules;GeneratorModules-01-02-03
> cmt co -r GeneratorModules-01-02-03 Generators/GeneratorModules [2]
# ================= working on package GeneratorModules version GeneratorModules-01-02-03 path Generators
# get top files
# get branches GeneratorModules cmt doc src share
# Required version v17r10 of package CLHEP incompatible with selected version CLHEP-00-01-07
Creating setup scripts.
Creating cleanup scripts.
Installing the baseline directory
> cd Generators/GeneratorModules/*/cmt
> cvs status -v requirements [3]
===================================================================
File: requirements Status: Up-to-date
Working revision: 1.26
Repository revision: 1.26 /atlascvs/offline/Generators/GeneratorModules/cmt/requirements,v
Sticky Tag: GeneratorModules-01-02-03 (revision: 1.26)
Sticky Date: (none)
...
- taginfo is used to query what was the tag of
this package in the release 3.0.1
- the -r option is used to select a particular
tag for this version
- one may verify that this package has got a sticky
tag, meaning that no modification can be committed
In this section, we explain how to obtain into the work area
all packages belonging to a given container for a particular
release. The example here uses release 4.0.0, and it assumes
that you have set the to be your default release (see [3.2]). The containers
available in release 4.0.0 may be shown by the following
command:
> taginfo release -name=4.0.0 | grep -i containerPackage
topContainerPackage;offline/Applications/;Applications;Applications-01-04-12
topContainerPackage;offline/Calorimeter/;Calorimeter;Calorimeter-02-00-01
topContainerPackage;offline/Control/;Control;Control-01-03-04
containerPackage;offline/Control/AthenaExamples/;AthenaExamples;AthenaExamples-01-02-25
topContainerPackage;offline/Database/;Database;Database-00-00-55
topContainerPackage;offline/Applications/;Applications;Applications-01-04-09
...
containerPackage;offline/LArCalorimeter/LArCnv/;LArCnv;LArCnv-00-05-05
...
Then the checkout operation is performed in two steps:
-
retreiving the container itself using the correct tag for
release 4.0.0
> cd ${HOME}/MyTest
> cmt co -r LArCnv-00-05-05 LArCalorimeter/LArCnv
-
retreiving the packages directly contained in the container
> cmt co -requirements LArCalorimeter/LArCnv/LArCnv-00-05-05/cmt/requirements
where the arugment to -requirements is the
requirements file of LArCnv that you have checked out.
Once all packages are retreived, some global operations may be
performed on them via the cmt broadcast command as follows:
> cd LArCalorimeter/LArCnv/LArCnv-00-05-05/cmt [1]
> cmt broadcast [2]
> cmt broadcast cmt config [3]
> cmt broadcast gmake [4]
- We move to the cmt directory of the container, so as to
have a consistent vision over all packages of the
container
- This minimal broadcast command (with no shell action
specified) is only meant to display the list of packages
that will be reached during any broadcast command. This
dummy command is also useful to verify that the CMTPATH
is correctly setup (since broadcast is applied onto all
packages reached from the first item of CMTPATH).
- This is ONLY needed to be done ONCE. This creates setup
and cleanup scripts in each
package. Normally cmt config is done at checkout
time, but this has not been implemented for the
-requirements option.
- Then it's likely that you will want to rebuild them
The cmt broadcast command may also
be issued from the cmt directory of the TestRelease
package. Make sure you have a TestRelease package checked out
into your working area:
> cd ${HOME}/MyTest
> cmt co TestRelease
Go to the cmt directory of TestRelease:
> cd TestRelease/TestRelease-00-00-14/cmt
Modify the uses in the requirements file. Change
use AtlasRelease AtlasRelease-*
to
#use AtlasRelease AtlasRelease-* [1]
use LArCnv LArCnv-* LArCalorimeter [2]
- Comment out the dependency on AtlasRelease which in turn
depends on ALL packages in the release
- Add use for the package LArCnv, all versions, which is a
sub-package of LArCalorimeter
Then simply broadcast the gmake command:
> cmt broadcast gmake
where we have assumed that a cmt config already has
been broadcast ONCE.
Figure 1.