The following assumes you have a working installation (your own
if you're working from a desktop or laptop, otherwise central
installation provided for you)
of
CMT
and also of MRvcmt if you plan to use it, and that you have
set up a cmt path including
a directory for your own packages (normally first in the cmt path).
You should have some familiarity with these tools and also with
cvs.
From MRvcmt
Click on the menu and select
. A dialog will come up in which you must
specify package name and a version for the package. By default the new
package will be created in the first directory in your cmtpath, but
the dialog allows you to override this if you wish.
From command line
The following creates a package myPackage under directory
myTopDir.
Fixed text required for the command is
in green.
$ cd myTopDir
$ cmt create myPackage v1r0
Naming and numbering of new packages
The initial version specification should be
of the form
vm
rn, e.g.
v1r0 or
v0r0.
Package names should
start with a lower-case letter unless the package will be using Gaudi,
in which case it should start with a capital letter. GlastRelease
packages generally use camel case naming (successive words are capitalized,
as in
camelCase) where as ScienceTools package names
mostly separates words with underscores, as in
not_camel_case.
Interface packages for external libraries don't necessarily follow
these conventions; many have names
which are all caps.
What brand-new packages look like
They have two subdirectories (aka folders):
cmt and
src.
The latter
starts out empty.
cmt always has a file called
requirements
(the cmt requirements file) and will have some other files having to
do with configuring and building the package. Exactly what they
are depends on your platform. You never edit them directly; cmt manages
them.
Folders
In addition to the two folders cmt makes automatically, you'll need
at a minimum a
doc folder and usually a folder named
after the package for public include files. Some packages have
xml
or
data folders or both. Only add these if you find you need
them.
.cvsignore
Contents is a list of files (names may include * used as a wildcard) which
cvs will ignore during commands such as
cvs import and
cvs update.
See
more details. The recommended contents of these files
may change as we move to newer compilers and versions of CMT. Look at
well-maintained packages
via ViewCVS to
determine current practice.
requirements
This file controls how a package is built and what is accessible at run time.
It is
described more fully here but,
since its
form varies depending on what products are to be built, it's also a good idea
to look at examples
via ViewCVS.
There are at least three kinds of packages: those that build a static library,
those that build a Gaudi component (dynamically-loaded shareable or dll)
and those that build a non-component shareable/dll. See
facilities for a
static library package,
LdfConverter for Gaudi component
example, and
xmlBase for non-component shareable.
release.notes
Every package should have a
doc folder and that folder should contain
a file called
release.notes. Each time the package is tagged a line
should be added to this file, as in
this example. If you use MRvcmt for tagging, it will
present the file to you for editing. Furthermore, if, as in the example,
you include a line with "EOH" at the bottom of all header lines, MRvcmt will
fill in the first three fields (version, date, user) for you.
mainpage.h and Doxygen documentation
Created: 9 February 2006 J. Bogart
Last modified: