|Offline Documentation: [Offline Category] [FAQ] [Howto] [Reference] [Manual]|
|This article is part |
of the Offline Documentation
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/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
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:
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 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.
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
- 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 ...
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
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.
See this topic on how you can use "nuwaenv" to set up your environment to use your personal project.
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]|