Project

General

Profile

Editing Code

Overview

The following is an outline of how to edit the code. Step 3 is usually done only once; i.e., the first time one wants to start editing code.

  1. source the setup file to set the SRT related variables
  2. cd to a working directory
  3. create a test release
  4. cd into test release directory and work on code

Whether you are using the Fermilab installation or have installed novasoft on a local machine, the steps to editing the code are the same. The main benefit of SRT becomes apparent in this process, namely that it allows users to create test releases that are distinct from the local base release. In this system, multiple users can work on several packages from the base release at once without interfering with each other.

Please be sure to follow the coding conventions enumerated below.

Coding Conventions

Please read the CodingConventions document that is located in the Demo/docs package.

Using/Creating a Test Release

A test release should contain only those packages that the user plans to alter. The remaining packages will be linked from the stable base release, most commonly development. To create a test release 'cd' to a directory in your own personal development area which should be in /nova/app/users/

% newrel -t development mytestrel

where development is the name of the base release (change for tagged versions) and mytestrel is the name of the test release directory (change appropriately).

Only one test release need be created. It can hold all packages that the user wishes to modify. However, in certain circumstances it can be useful to set up multiple test releases, such as having a test release for development code and one for a frozen point release.

Adding NOvASoft Packages

Once the test release is made, the user should cd into the directory and add packages to edit by doing

% addpkg_svn -h package

where the -h indicates that the package should be checked out from the head of the repository and package is the name of the package. If you have a test release based on a frozen release, SYY-MM-DD, then do

% addpkg_svn package <tag>

where <tag> is the svn tag for the version of that package you wish to checkout. See the $SRT_PUBLIC_CONTEXT/setup/packages-SYY-MM-DD file to determine the tag for the package.

Adding NuSoft Packages

If you want to add a NuSoft package (EventDisplayBase for example) to your test release then you must do it like so:

% addpkg_svn -hd http://cdcvs.fnal.gov/subversion/nusoftsvn -s nutools EventDisplayBase

This gives a read-only version, so you shouldn't ever really need to do this.
If you have write-access to the nusoftsvn/nutools repository then you need to add the package as p-nusoftart like so:

% addpkg_svn -hd svn+ssh://p-nusoftart@cdcvs.fnal.gov/cvs/projects/nusoftsvn -s nutools EventDisplayBase

Creating Packages

If you wish to create a package in your test release, simply do

% mkdir mypackage

where mypackage is the name of your new package. You will need to create a GNUmakefile inside the directory. You can copy examples of these from existing packages. You will also want to create a link from your new package to the include directory of your test release in order to compile your package,

% cd include
% ln -sf ../mypackage mypackage

Removing Packages

DO NOT under ANY circumstance do a rm -r package. Don't even do this and then remove the include link. There are secret links you will not know about and a month later your test release will mysteriously break. Instead, you must always do:

% make <package-name>.clean
% rmpkg -f <package-name>

This removes the package and all the insidous links that it has made, including the .so files in one's lib folder.

Compiling Packages

Compiling packages under the SRT environment is fairly straightforward. First, one needs to run the following command at the top of the test release

% srt_setup -a

This command sets the $SRT_PRIVATE_CONTEXT variable to the current directory and also sets paths for the compilation. To compile a package, do

% make package.all

If a clean compilation is needed, the user should do

% make package.clean

before compiling. Of course when compiling code replace 'package' in the above examples with the name of the package in question; e.g., RecoBase.

Backporting bug fixes to a frozen release

A request must be made to do this! Request to Jan Zirnstein (zirnstein AT physics.umn.edu) and/or Gavin Davies (gsdavies AT iastate.edu).

Editing code remotely using Emacs and Tramp

Emacs has a handy facility called Tramp that will scp a file to your local machine, allowing you to edit it without network latency, and then scp the saved changes back to the original location. To use tramp add the following to your ~/.emacs file

(define-abbrev-table 'my-tramp-abbrev-table
  '(
    ("aliasname" "/ssh:nova-offline.fnal.gov:/nova/app/users/my_user_name/")
    ))

where "aliasname" is the name you want to use for an alias, "nova-offline.fnal.gov" is the name to use the load-balancing login. It will land on one of the nova VM's, and "my_user_name" is your username on that machine.

Restart Emacs, and then attempt to open a file with "ctrl-x ctrl-f". Replace the "~/" in the file open dialog window with "aliasname" and press tab to access the remote directory.