%CERTIFY%

This information is currently being transferred to the the Computing Workbook and the new Software Development Workbook. Material that has already been transferred (or is obsolete) is greyed out. Please do not update this information here but update the relevant Workbooks instead.

change the build mode (debug, optimize, etc)

This has been moved to WorkBookAdvancedSetup

This assumes you already have set up a cmthome directory as described in WorkBookSetAccount. Do

source ~/cmthome/setup.sh -tag_add=dbg or -tag_add=opt  or -tag_add=prof 

Check that CMTPATH and CMTCONFIG are what you want and then setup and rebuild (no clean-up necessary):

source ./setup.sh 
gmake 

or, if several packages have been checked out in the same user area:

source ./setup.sh 
cmt broadcast gmake

cleanup the binaries

From the cmt directory do:

rm -fR ../i686*  
or even better, since more generic
gmake binclean
or, if several packages have been checked out in the same user area:
cmt broadcast rm -fR ../i686* 
where i686* is the directory where the binaries are being built (CMTCONFIG).
cmt broadcast gmake binclean

change the release

First select the new release the usual way (generally done by editing your ~/cmthome/cmt requirements file):

source ~/cmthome/setup.sh 

Update the environment variables (assuming you are in the cmt directory of a package, e.g. TestRelease):

source setup.sh 

Then clean-up the binaries (as above) and rebuild everything:

gmake 
or, if several packages have been checked out in the same user area:
cmt broadcast gmake 

If you have checked out and modified some packages from CVS, before rebuilding you need to update each package to their possible new version in the new release. To do this, the recommended way is to do the following. cd to the top directory of the package. Find the new tag of the package in the release (described elsewhere). Then to see what has changed:

cvs diff -r < new package tag > 
To merge your own changes with the packages changes:
cvs update -r < new package tag > 
Watch out for message like "Conflicts". This means that your modification and the package modifications are in conflicts, typically the same lines have been edited. The files were this happens need be edited, area of conflicts are indicated with ">>>>>>>>>>>>.". Do not forget to update jobOptions files in /run directory if necessary.

change a compiler option

Let's suppose you want to use -pedantic-errors when compiling a given package. Edit the cmt/requirements file. Add the following lines:

private 
macro_append cppflags " -pedantic-errors"
(be careful not to forget the leading space). The new compiler option will be used whenever a file of this package is recompiled. If private: is omitted, the new compiler option will be used also in any package which depend on it directly or indirectly.

select a work area

A work area is a directory where you check out a package and work on it. If only one package is considered, you have nothing to do to qualify a directory as being a work area. Thus for such a simple scenario you may skip this paragraph.

However, when several packages are expected to be developped in a given work area, CMT needs to know it, so as to include it in the package search path list (this is required to identify where to search used packages). This is simply done by installing the work area in the environment variable CMTPATH.

This is possible using shell commands :

sh> export CMTPATH=${HOME}/MyTest:${CMTPATH}
csh> setenv CMTPATH ${HOME}/MyTest:${CMTPATH}

But the preferred method is by installing the specification in the login requirements file:

path_remove  CMTPATH "MyTest"          [1]
path_prepend CMTPATH "${HOME}/MyTest"  [2][3]

  1. this will first cleanup CMTPATH from any item containing the string "MyTest"
  2. this installs the selected work area at top of the path list
  3. the order in CMTPATH is relevant, left-first items are searched first

Then it might even be useful to declare several alternate work areas, either to be able to switch between different developer contexts, or to combine them.

To obtain this, each path_prepend statement should be protected by a dedicated tag as follows:

macro d57 "/afs/cern.ch/atlas/maxidisk/d57"    [1]

path_remove CMTPATH "MyTest"                   [2]
path_remove CMTPATH "work"                     [2]

path_prepend CMTPATH "" dev "${HOME}/MyTest"   [3]
path_prepend CMTPATH "" d57 "$(d57)/MyTest"    [3]
path_prepend CMTPATH "" fix "$(HOME)/fix"      [3]

  1. define a macro for using this maxidisk
  2. general pre-cleanup operations
  3. alternate additions to CMTPATH

Then selection of work areas will be done using:

> source setup.[c]sh                 [1]
> source setup.[c]sh -tag=dev        [2]
> source setup.[c]sh -tag=d57        [3]
> source setup.[c]sh -tag=dev,fix    [4]

  1. default behaviour: CMTPATH is cleaned up from any work area
  2. dev work area is selected: ${HOME}/MyTest
  3. alternate work area in maxidisk
  4. dual work area: dev and fix

extract information from CVS

This information has been moved to SoftwareDevelopmentWorkBookBrowseCVS.

Useful command to extract info from CVS is listed below. Note that viewcvs is very useful to see what has recently be modified in a package in CVS, especially for one given file. (LXR is more indicated to search keywords through the full cvs repository ). cvs command lines are more useful to compare different version of full packages (rather than individual files) or to compare private modifications to given tags. To have the best readable output, it is recommended to have in one's home directory a file .cvsrc with contents

diff -u 
update -d 

Some useful commands, from the top directory of a given package:

  • cvs -n update -r < new package tag > list modified files either by you or by someone else

  • cvs diff -r < new package tag > list differences between your version of the package and the one with the given tag. Note that to look at different version of a package in different releases, the release tag offline-xx-yy-zz can be used (this is possible as soon as a release is tagged).

  • cvs diff -r HEAD list differences between your version of the package and the HEAD of CVS

  • cvs status -v cmt/requirements list all the tags of a given file.

From any directory:

*cvs rdiff -r -r offline/Deconstruction list differences between two versions of a given packages(one of the tag can be HEAD).

Using Doxygen

See DoxygenDocumentation.

Topic attachments
I Attachment History Action Size Date Who Comment
GIFgif branch.gif r1 manage 7.2 K 2006-09-20 - 10:48 UnknownUser Displaying a cvs branch with ViewCVS
Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2008-06-23 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback