Developing the Code(Unix)

Click on to return to start of page

Preliminaries

Before writing or modifying any code, please familiarize yourself with our coding standards.

Table of Contents

Modifying a package and checking it back into the repository

To modify and then check in changes made to a package, you must start with the HEAD revision of the files in the package. The easiest way to do this is to checkout the HEAD version of a package and assign it a higher revision number than what is currently being used by your application.

For instance, suppose your current installation uses the v1 version of heavy. You want to make changes to this package. You shall check out the HEAD version of heavy. You will, however, have to put this package in a directory structure that CMT understands, such as v1r1/ or v3r6/. Using cvsweb check what the latest tagged version of this package is, then increment it one to get the version you should use. Assuming that v1 is the latest tag of heavy, we shall therefore assign our checked package to a directory called v1r1. Now check out the package as follows

CMT has no mechanism to check out the HEAD revision of a package, so it is necessary to use cvs commands. For the example above, use the following commands

mkdir heavy

cd heavy

cvs checkout -d v1r1 heavy

If you have control over the entire code installation then you can do the checkout described above alongside the other packages. If, however, you are working with a central installation (which you don't want or aren't allowed to modify) and only want to edit the one package then you should use the above checkout procedure in your own personal space. You then need to add this space to your CMTPATH (which you would have done while you set up CMT).// add hyperlink

In either case the purpose of checking out heavy to a directory called v1r1 is the same: CMT will now use your v1r1 copy of heavy, rather than the v1 copy of heavy that came with the central installation. You can now edit your copy of heavy as you please.

Once you have finished your changes you will want to rebuild the application to test your changes. If you have control over the whole installation this is simple: simply follow the instructions given in Building the Code on Windows and Unix . If, however, you do not have control you will want to check out your own copy of the application package (for instance gsim) into your own personal space. You can then use this package to build and run the application.// add hyperlink to the correct page

Once you've tested your code you'll want to check it back into the repository (specifically you'll be checking the code into the HEAD of the MAIN branch). You do this as follows

First move to the root of the package you've been editing

cd heavy/v1r1

then do

cvs commit -m "Detailed Log Comment"

This will recursively check in any modified files in the packages subdirectories (excluding files and directories in the .cvsignore file). The "Log Comment" should explain the changes you've made. As mentioned, the modified files will be checked into the HEAD of the MAIN branch.

Creating a new package

To create a package called "supergismo" with initial version "v1" do

cmt create supergismo v1

Note that this command will create the package in the current directory.

The new package will have two directories: cmt and src. The src directory will be empty and the cmt directory will contain a skeleton requirements file. This requirements file only specifies the package name; all the rest you need to fill in yourself.

Checking a new package into repository

A preliminary step is to add a file called ".cvsignore" to the root of the package you wish to check in. This file will specify which directories cvs is to ignore when importing. This is so that cvs does not import the directories like Win32 or sun4x_56, which only contain libraries and executables (which should not be in the repository). It should also exclude the setup and make files that may have been created during the testing phase.

Suppose you have a new package called "newPackage" (with initial version v1). You would need to create a file newPackage/v1/.cvsignore that had the following lines as its content

sun4x_*

i386_linux*

Win32*

Visual

setup.*

*.mak*

You can create the file with your favorite editor.

Next check the new package into the repository using these instructions

Move to the root directory of the package you've created.

cd newPackage/v1

Now import the package to the repository

cvs import -m "First import" newPackage GLAST v1

The option "newPackage" specifies that the files will get imported into a directory called newPackage. The argument "GLAST" specifies the vendor and the argument "v1" specifies the vendor tag.

Updating the Admin Package

The software group maintains a package called Admin, whose purpose is to assign the ownership of each package, as well as define which packages are checkout packages. The package contains two files

package_ownership_list.txt - This is a list of the used CMT packages, as well as the owner of the package.

checkout_package_list.txt - This is a list of the CMT checkout packages.

Updating the Admin package

If you add a new package to the repository, you should update the Admin package to reflect this. You'll need to update the HEAD of Admin, so use vcmt can be used to checkout the HEAD on Windows. The format of the files is simple and should be self-explanatory.

Adding an External Library

It is possible to use an external library with an application that is built using CMT. To do this you need to create a CMT package that will serve as an interface between CMT and the external package. Such a package is called a glue package.

The first step then is to create a package . The package name should make clear which external library it refers to (i.e. the package CLHEP is a glue package for the CLHEP library). It is also useful if the version of the glue package corresponds to the version of the external library (i.e. the CLHEP glue package has version v1r5 to correspond to the 1.5.0.0 release of the CLHEP library).

The next step is to edit the requirements file for your glue package so that CMT will be able to find the include files and libraries. Shown below is the requirements file for CLHEP. We shall go through how things need to be set

package CLHEP
version v1r5

use EXTLIB v2r2

include_path "${CLHEP_DIR}/include"

public

set CLHEP_DIR "${EXT_DIR}/CLHEP/1.5.0.0"

macro CLHEP_linkopts "${CLHEP_DIR}/CLHEP/libCLHEP.a" \
VisualC "${CLHEP_DIR}/lib/Clhep.lib"

The first step is to specify the base directory of your external library (in this case CLHEP_DIR). In general, it is hoped that all external libraries used for GLAST code reside in the same directory, which is specified by the environment variable EXT_DIR. The EXT_DIR variable is set in the EXTLIB package which has been done in the setting up the external libraries step; it is therefore necessary to include the EXTLIB package with the "use" command.

Using the variable specifying where to find the external library you now set the include and linking paths. The "include_path" command specifies where to find the include files. The "CLHEP_linkopts" command specifies where the external library is; simply replace "CLHEP" with the name of your interface package. Notice that for the default for CLHEP_linkopts is "libCLHEP.a", but on a Windows system it is set to "Clhep.lib". In this way you can customize your glue package so that it works on both Unix and Windows.

Checking changes to a package

Some Not-So-Routine Operations

modifying the compiler settings

Last Modified December 02, 2002

Back To Main Menu Previous Step Next Step