CMT: An Introduction
Tip: In conjunction with the Concurrent Versioning System (CVS), the Configuration Management Tool (CMT) is used to manage the build of a software release. It is CMT that knows how to do a recursive checkout.
Note: MRvcmt is a frontend GUI designed to facilitate such checkouts. Though MRvcmt is the recommended method, developers using a Linux machine may also use glastpack to do recursive checkouts.
Configuration Management Tool (CMT)
The Configuration Management Tool consists of a number of package-oriented management conventions and several shell-based utilities for configuration management that can be used in conjuction with CVS. In addition, CMT supports the same build environment in both Linux and Windows. GLAST offline software uses CMT's definition of packages, package directory structure, requirements file, and CVS Tagging Conventions.
Using the requirements file, CMT is capable of generating:
CMT is designed to work with packages organized in a particular structure.
Package Directory. Each package is contained in a directory named after the package itself.
Package Subdirectory. The package directory contains a single subdirectory which is created "on the fly" and named after the tag of the package being checked out; this subdirectory is then referred to as the package root directory. Thus, if you are checking out TkrRecon/v4r3 on SLAC Public using MRvcmt, you would enter the package name (TkrRecon), select the package tag (v4r3), and set up a path to the CMT executable for the release version (BeamtestRelease, GlastRelease, EngineeringModel, or ScienceTools). In your user work area, a TkrRecon directory and a v4r3 subdirectory (i.e., the root directory) would be created on the fly; the package would be configured and built, and all code and administrative files, as well as the target directories for the built components, placed into directories sitting underneath this package root directory.
GLAST Offline defines several standard directories which exist underneath the package root. This consistency aids both automated procedures accessing the package and the end-users. The only directory required to exist in this scheme is the cmt directory. The following is a list of the directories in this convention.
Each package has a CMT requirements file containing the information required to build its components (typically libraries and applications) and to use them at run time (e.g., where its shared library is located).
Dependencies. Other packages on which a package depends are specified by use statements. Each package's requirements file has access to public information in the requirements files of the other packages, enabling it to know which compiler options to use and which libraries to link against.
Parameters. Parameters of build and test tools as well as deployment tools are also located in the requirements file.
Example: Requirements File for a Gleam Package
A CMTPATH file is a text file that contains a list of directories where packages are/will be stored. As shown in the following examples, directories are separated by a single colon:
Example #1: Linux. CMTPATH=/nfs/farm/g/glast/u06/mydirectory:/nfs/farm/g/glast/u06/someotherdirectory
Example #2: Windows. CMTPATH=C:\glast\packages:C:\glast\otherdirectory
Caution! By convention, when CMT searches for a package, it uses the first occurrence in its CMTPATH; take care to assign the order properly.
Note: Inside your working directory you will find a file named "CMTPATH". This file has the syntax of the CMT .cmtrc file, and is managed via "add" and "remove" commands. Paths do NOT inherit; for example, if area A needs area B in its CMTPATH, and B requires C, A must explicitly add B and C.
Other Useful Links: