Offline Documentation: [Offline Category] [FAQ] [Howto] [Reference] [Manual]

Offline Documentation

This article is part
of the Offline Documentation

Other pages...

Offline Category
FAQ
How Tos
Reference
Manual
Getting Started
Software Installation

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

cmt/project.cmt

file. This file is like the per-package cmt/requirements file 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 cmt/project.cmt 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 cmt/project.cmt 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 "v3r4p5".

To tell CMT where to find a package, there are two ways:

CMTPATH

The CMTPATH env. 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.

CMTPROJECTPATH

The CMTPROJECTPATH env. 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 CMTPROJECTPATH less tedious than explicitly listing each project in CMTPATH. When looking for packages, CMT will walk the CMTPROJECTPATH looking for (sub)directories containing cmt/project.cmt and 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 in order to override things in various PATH-like variables
The package is located with the same path relative to the top of your project in order for the "use" commands in the cmt/requirements files to still work.

You can use cmt show uses to confirm your overriding package is being picked up.

Example

This assumes you have already installed a NuWa release. See Offline_Software_Installation for how to do this.

Setting up a personal project takes three stages.

1. Set up the area to hold projects, make a project and populate it with packages 2. Set up your base environment and the build environment for your project and then build your packages 3. Set up the runtime environment to use your newly built project

Set up your project area

Copying a Package from NuWa

Here a personal project called "mynuwa" is made and populated with a single package from SVN:

mkdir -p /path/to/myprojects/mynuwa/cmt
cd /path/to/myprojects/mynuwa/cmt
cat > project.cmt
cd ..
svn checkout http://dayabay.ihep.ac.cn/svn/dybsvn/dybgaudi/trunk/Reconstruction/CenterOfChargePos

Further projects can be placed in the "/myprojects/" area.

Maintaining Your Own Project in SVN

See this topic for generic information on maintaining your own code in a "people" area. You can keep individual packages or whole projects in SVN.

Make your area if it isn't already there:

svn mkdir http://dayabay.ihep.ac.cn/svn/dybsvn/people/myname

Make a project

svn mkdir http://dayabay.ihep.ac.cn/svn/dybsvn/people/myname/myproject

Then, like above, make a working area:

mkdir -p /path/to/
svn co http://dayabay.ihep.ac.cn/svn/dybsvn/people/myname/myproject
cd myproject
mkdir cmt
cat > project.cmt
svn add cmt
svn commit -m "Start my project"

Setup for building and build

You will set up your environment for the base release and then set up enough environment from your personal project to build the package.

cd /path/to/base/NuWa
source setup.sh
cd /path/to/myprojects/mynuwa/CenterOfChargePos/cmt
cmt config
source setup.sh
make

Notes:

the "cmt config" is only needed if setup.sh does not yet exist
until the "make" is done your project has no InstallArea/ and thus the "source setup.sh" done at this stage does not set any environment variables that refer to this InstallArea/

Setup for running

Now that the "make" has populated your project's InstallArea a second sourcing of setup.sh needs to be done to, in particular, set PATH-like variables:

source setup.sh
nuwa.py ...

Continuing

At this point you can re-make and re-run nuwa.py with no concerns about additional sourcing of setup.sh.

Returning with a clean shell

If you have logged out and you later come back to your project you need to do:

cd /path/to/base/NuWa
source setup.sh
cd /path/to/myprojects/mynuwa/CenterOfChargePos/cmt
source setup.sh

Multiple Packages

If you have more than one package in your project that you want built, make a "release" package that has nothing but a bunch of "use" commands in the requirements.

Automating

See this topic on how you can use "nuwaenv" to set up your environment to use your personal project.

Pitfalls (gotchas)

Mostly a summary of the information above but take care of the following:

CMTPROJECTPATH holds a list of directories containing project directories and should not contain the project directories themselves.
The Project/cmt/ directory holds a project.cmt file and never a requirements file.
The project.cmt file must "use dybgaudi" (or some other project) at the least unless it is truly stand-alone.
Packages go under Project directories.
You never need to set CMTPATH yourself. If you find yourself doing so, the problem is actually somwhere else.

Offline Software Documentation: [Offline Categories] [FAQ] [Offline Manual Category]

CMT Projects

Contents