• Introduction
• Installation of CMT
• Working model
• Creating a new package
• Working with CMT
• CMT requirements files

Introduction

This page addresses some issues of using CMT within the L1Calo software project.

Installation

For my convenience (Ive tried several versions) I put all the above steps into a script downloadcmt.pl in our scripts package. The script needs to live in your CMT directory (ie somedir/CMT in the example below).

Having downloaded (or built) a version (eg v1r18p20041201) of CMT in some directory, you need to source the setup script. It is convenient to do this in your .login or .profile files:

  source somedir/CMT/v1r18p20041201/mgr/setup.sh

Working model

The normal CMT approach is to keep all the compiled binaries in architecture specific directories within the package directory structure. This is useful while developing a package. In addition to this, the Online working model defines an installation area where all the binaries and C++ headers of all packages can be installed together. This can then be the basis of a binary release.

CMT defines a minimal required directory structure. Beneath the package directory, is a (now optional) subdirectory for each tagged version of the package (though the Online group recommend only dealing with one version at a time!). Within the tag subdirectory there must be a "cmt" directory. The convention for the tag is "<package>-vv-rr-pp" where "vv", "rr" and "pp" are two digit version, release and patch numbers. Repeating the package name seems unnecessary but seems, sadly, to be the ATLAS standard.
NB recent versions of CMT allow working without the extra version directory and we are adopting this new style.

CMT normally expects to find source code in "src", though you can override this. The Online group typically use "src" for C++ code which will be part of a library and "jsrc" for Java code destined for a jar file. Code for applications and other test programs is generally kept in separate directories (eg "bin", "test") - but this is largely up to you.

However the ATLAS convention for accessing C++ header files does require you to keep them all in a single directory named after the package. With this convention the header files are used with "#include package/header.h".

So the typical directory structure (without the optional version directory) might look like:

  workarea/<package>/cmt
                    /<package>  (C++ header files)
                    /src        (C++ source for libraries)
                    /bin        (C++ source for applications)
                    /test       (C++ test programs)
                    /jsrc       (Java source for jar files)

  CMTCONFIG="i686-slc3-gcc323-dbg"; export CMTCONFIG

Creating a new CMT package

  cd workarea/LVL1/l1calo
  cmt -without_ver create myPackage myPackage-00-00-00
  cd myPackage
  mkdir myPackage bin test     # CMT already created cmt and src directories

The package can the be entered into CVS as a new l1calo package. The prescription for doing this is on our local CVS page.

Working with CMT

Also look at our web page on how to set up the L1Calo software.

CMT Requirements File

But in the meantime, there is a little detail on some of the features provided in our use of CMT which are defined in our L1CaloPolicy package.

You can also look at example requirements files from our existing packages. Follow the links below then click on the "Rev." link for the requirements file:

• rcL1Calo: a fairly typical requirements file containing a library built with code from several classes in src, some public applications to be installed and some private test programs.
• cpRodServices: shows how to generate register classes using the regbuild command.