- Table of contents
- Working with NOvA offline software in CMT
Working with NOvA offline software in CMT¶Some of following are from https://wiki.bnl.gov/dayabay/index.php?title=CMT_Packages and https://wiki.bnl.gov/dayabay/index.php?title=CMT_Projects.
- Quick Start
shell> cd /path/to/nova-trunk shell> source setup.(c)sh shell> cd novafmwk/novaRelease/cmt shell> source setup.(c)sh shell> ana [options] shell> evd [options]
- CMT Package
We organize our software into units called "packages" that are organized with CMT.
- Types of packages
We use several types of packages, including:
Software: these hold source code to build applications and/or libraries.
Glue : these hold CMT configuration to "glue" in external, 3rd party packages.
Policy: these provide rules telling CMT how to build software or how to setup the environment for running the software
- Anatomy of a package
The contents of a package are all held in a directory named after the package: . In this directory are one or more subdirectories. What subdirectories exist depends on what the package is supposed to be used for. A sample of required or optional subdirectories follows
The only truly required subdirectory is . And this requires the file:
The [[CMT requirements file|
requirements]] file describes the package to CMT.
Because we do not used versioned subdirectories, you will also need a file: which holds the version of the package, for example "v0" or "v1r2p3".
Other files will be placed in
cmt/as CMT configures or builds the package.
All source code (and private header) files your package may have go in
- Creating a new package
First go to a directory where you want the package to sit. It is recommended that you organize your packages into one or more CMT Projects.
shell> cd /path/to/myfirstproject shell> cmt create PackageName v0
This is minimal, see CMT requirements file for more information.
- Types of packages
- CMT Projects
CMT provides a way to group a set of related packages together in a project.
- What is a CMT Project?
A CMT project is simply a directory that holds a number of CMT packages, each in their own sub directory. To be a proper CMT project it must declare itself as such using a file. This file is like the per-package
cmt/requirementsfile in that lists various CMT configuration information. In particular it might contain:
project name any other projects to "use" any CMT "strategies" to employ one of its packages as a main "container" that builds all packages
If a bare directory, without any file, is used to collect one or more packages, CMT may get confused when performing some operations. So, it is best to always have a file.
- Using a CMT Project
To use packages from a CMT project by your own package you must tell CMT what package to use and give it hints on where to find it. You tell CMT what package to use with the usual
use PackageName [optional-version] [optional-parent]
Where the version string is something like "
v*" or more the explicit "
To tell CMT where to find a package, there are two ways:
CMTPATHenv. var. holds a colon (":") delimited list of directories containing packages. This is useful if you have only a small number of projects you want to use together.
CMTPROJECTPATHenv. var. lists not where to find packages, but where to find projects containing packages. Typically it is convenient to put all or most projects into one or a small number of directories. This makes using
CMTPROJECTPATHless tedious than explicitly listing each project in
CMTPATH. When looking for packages, CMT will walk the
CMTPROJECTPATHlooking for (sub)directories containing
cmt/project.cmtand include all that it finds as potential sources of packages.
- Overriding packages in other projects
You can override a package in another project by making or copying one with the same name in your project. In order for this to correctly work assure:
- The package has the same name
- The package is located with the same path relative to the top of your project
- The CMTPROJECTPATH was correctly set up with your project listed first
After creation, you will need to
source setup.shto adjust environment variables (note bug #105 means you have to do this twice).
You can use
cmt show usesto confirm your overriding package is being picked up.
This assumes you have already installed a NOvA release or use the pre-installed release. See Offline Software Installation for how to do this.
Next, pick a location to hold your own projects.
shell> cd ~myworkarea shell> cmt create_project myfirstproject shell> cd myfirstproject shell> echo "" >> project.cmt shell> echo use novafmwk >> project.cmt shell> echo build_strategy with_installarea >> project.cmt shell> echo structure_strategy without_version_directory >> project.cmt shell> echo setup_strategy root >> project.cmt
Finally, you may make your own CMT packages or bring down copies from SVN. If you plan to use packages from the release you must take care to keep the same directory structure. For example, if you want EventDisplay you should make sure it is put in
shell> cd /path/to/myfirstproject shell> svn co svn+ssh://email@example.com/cvs/projects/nova/novafmwk/trunk/EventDisplay EventDisplay shell> cd /path/to/nova-trunk shell> source setup.sh # basic setup shell> cd /path/to/myfirstproject shell> CMTPROJECTPATH=`pwd`:$CMTPROJECTPATH # add you project area shell> cd EventDisplay/cmt shell> cmt broadcast cmt config # Create the setup.sh file - only need to do this once shell> source setup.sh # Setup env for package - do this on each login shell> cmt br make # May be needed to completely rebuild your environement
Follow SVN Howto if you make any changes to the code and want to share with others.
- What is a CMT Project?