CMT

CMT is an acronym for Configuration Management Tool, designed and maintained by Christian Arnault at LAL in France. It is capable of generating gmake-style makefiles as well as Microsoft Developer Studio project and workspace files, and Visual C++ compatable makefiles (NMAKE). The configuration for each package revolves around a central requirements file for that package. This file defines the necessary macros, environment variables, and dependencies to compile, link, and execute the software defined by the package. In the context of CMT, a macro is a variable defined within a package’s requirements file that is substituted throughout the scope of a dependent package’s requirements file by CMT but is not exported as an environment variable. Macros are specified within a requirements file by the obvious ‘macro’ keyword. An environment variable may be specified in a requirements file in a similar manner by using the ‘set’ rather than the ‘macro’ keyword to define the variable. A ‘uses’ declaration within a requirements file establishes a dependency from one package to another, and a package with the uses declaration in its requirements file is said to be the dependent, or client, of the package described in that declaration – the dependee or provider.  Typically, all macros and variables declared in the provider’s requirements file are exported to all of its dependees. CMT allows for control over which variables are exported by allowing for public vs. private declarations within the provider’s requirements file. This brief summary of the overall function of CMT does not do justice to the inherent flexibility and robust support it provides for maintaining a software configuration. Further documentation is available via the official CMT web-site:

http://www.lal.in2p3.fr/SI/CMT/CMT.htm

 

CMT is designed to work with a directory structure which incorporates both the package name as well as the version and revision number of the package. It is possible to have multiple versions of a single package within this framework. The code and administrative files, as well as the target directories for the application code, fall into directories which sit underneath what is referred to as the package root directory. The highest level directory for a package is a directory whose name matches the package itself. Within this directory sit directories for all of the available revisions of a particular package. Each version specific directory contains all of the code, administrative files, and any other necessary components associated with that particular version of that package. This directory is known as the package root for a specific version of the package.

In the figure at left, the directory gaudi/Gaudi/v6 is the package root for the Gaudi package, version v6. Configuration of a particular package is carried out within this package root directory and, in effect, this is what dependent packages ‘see’ when they are compiling and linking against one another. From the perspective of a dependent package, all manipulation and access to the underlying code, object files, libraries, etc. contained within the package is done relative to this package root directory.

By convention there are 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 underneath the package root in this scheme is the mgr directory (note that this directory can also be called cmt - see below). As described below, this directory contains the administrative files which define properties of interest to the configuration system. The following is a listing of the various conventional directories which are often found underneath a package root. This is not necessarily an all inclusive list, but the directory naming conventions demonstrated here should serve as a set of firm guidelines.

• mgr/cmt
• This directory contains all of the administrative files used to configure and define the package in the scope of the configuration management system. The most important file is the requirements file, which provides the configuration specification to CMT for the package.  NOTE: the convention on what this directory is called has changed over the course of the development of the GLAST code.  Consequently older packages will have an mgr directory, whereas newer packages will have a cmt directory.  Be aware that some of the documentation may therefore use the new convention and some the old.
• src
• This directory contains all of the source, or implementation, files for the package. In the case of C++, these are the files ending with the ‘.cxx’ or ‘.cpp’ extension. It may also contain private declarations (ie. C++ header files) which are not intended to be exported to other packages. This directory is generally private to the package, in that dependent packages are not expected to ‘see’ the content of the src directory. Files may be arranged in any manner – for example underneath sub-directories – however this may affect the way the requirements file expresses build information.
• <package name>
• This directory contains exported declarations for the package – mainly header files in the context of C/C++. Putting the publicly available declarations underneath a directory with the package name makes for a consistent pattern of includes declarations in the dependent packages. For example, if package A has a header file called A.h and package B depends on A, then to access that  header file code in package B (in the context of C++) would use: #include “A/A.h”. This works regardless of where the package root directories for A and reside in the overall file system.
• msdev
• This directory contains the Microsoft Developer Studio workspace and project files as they are generated by CMT. 

·         doc

• This directory contains documentation associated with the package. This is where Doxygen generated documentation will fall under this scheme.

CMT Commands

All CMT commands follow the basic structure:

        cmt <command>

 

Aside from some of the more global commands, all of the CMT commands are most easily executed from the mgr directory of the package concerned. Alternatively, one may explicitly specify the package and version number on the command line, like this:

cmt –package=<package_name> -version=<version> <command>

 

This will essentially move into the mgr directory for the specified package and execute the appropriate CMT command from there. From the command line, a list of the available CMT commands can be printed by typing  ‘cmt help’. 

Important CMT Commands

The following list elaborates upon the information provided in the standard CMT help for commonly used CMT commands.

    broadcast <command>

The broadcast command will execute the specified command in the package root directory of each of the packages depended upon by the current package – that is, the package within which the broadcast command is origininally invoked. Generally, the command should be encapsulated in quotes (so that it is parsed as a single command-line entry).

    build <target>

This command will build the files associated with the given target. Possible options are

•     constituent_makefile

Generates the Makefile for the package, which will then depend upon the file constituents.make

•     constituents_makefile

Generates constituents.make, which is responsible for making all of the libraries and/or applications for the package.

•     dependencies

Generates generates a gmake dependencies file for this package.    

•     msdev

Generates Microsoft Developer Studio project files and workspaces in the $PACKAGEROOT/VisualC directory.

•     win_makefile

Generates a Makefile for VisualC++ (NMAKE)

 

    check configuration

Checks the syntax of the requirements file for the specific package as well as that of all of its dependees.

    checkout [-R] –r <version>  <package>

This command will check out the specified package from the CVS repository into a CMT compatible directory structure and automatically builds the appropriate makefiles or Visual Studio project files. The package should be specified in terms of the absolute path from the root of the CVS repository (i.e. cmt/application). The –R option indicates a recursive checkout of all of the dependees as well.

    config

This command checks the syntax of the requirements file for the active package and all of its dependees, regenerates the setup and cleanup scripts, and refreshes all of the CMT macros for the active package based upon the values provided within the scope of the package requirements and the requirments files of all of its dependees.

    create <package> <version> [<area>]

Creates a new CMT package with the appropriate directory structure (using the version provided).  The src, and mgr directories are created along with a minimal requirements file, Makefile, setup and cleanup shell scripts. The optional area argument may be used to specify an alternate path where the package is to be created.

    setup [ -csh | -sh | -bat ]

This command will generate a command to set all of the necessary shell environment variables as specified in the requirements file for a particular package as well as all of its dependees. The –sh, -csh, and –bat options specify the format of the output – being compatible with ‘sh’ or ‘bash’, ‘csh’ or ‘tcsh’ and the Windows shell environment respectively. The output is generally piped to a file as a means of generating a script which establishes the environment necessary to run the executables associated with the current package.

    show <key>

The show command will display the value of the entities associated with the key from within the context of the current package.  The key should be one of the following values:

• author

Show the author of a given package.

• branches

Show all recognized ‘branches’ or subdirectories of the given package.

• clients <package> [ <version> ]

Shows all packages which express an explicit dependency to the specified package. If no version is specified, information for all versions is displayed.

• constituent_names

Shows all of the constitutents – or products – that are generated by the package.

• fragment <name>

Show all instances of the fragment with the name as ‘seen’[1] by the current package.

• fragments

Show all fragments ‘seen’ by the current package.

• uses

Displays all of the dependencies, recursively, for the current package. This command is particularly useful in determining whether or not a package, and all of its dependencies, have been configured properly.

• macros

Shows all CMT macros that have been defined either by the current package or any of its dependencies.

    system

This command displays the current platform and operating system that CMT is configured to run on. This is the same as the CMTCONFIG environment variable.

    version

Shows the current version of CMT.

    cvstags <module>

Shows all CVS tags associated with module in the CVS repository. Effectively this corresponds to the versions available for a given package.

    cvsbranches <module>

Shows all branches (sub-directories) within a given package in CVS. 

•  

---

R.Dubois
Last Modified (T. Lindner): 12/02/2002 11:40