Project

General

Profile

Developing NuTools Code

Below are step by step instructions for developing NuTools Code.

Check out the NuSoft repository

First determine a directory in which to develop the code,

mkdir some_working_directory
cd some_working_directory

This directory should be separate from any other code development area, i.e. separate from your experimental code.

Then checkout the head of the repository. If you have write access to the repository do

svn co svn+ssh://p-nusoftart@cdcvs.fnal.gov/cvs/projects/nusoftart/nusoftsvn/trunk/nutools

otherwise do

svn co http://cdcvs.fnal.gov/subversion/nusoftsvn/trunk/nutools

Instructions for committing changes from a read-only check out are below.

Edit code

From

some_working_dir/
do

cd nutools

and start editing the package you want to work in.

Build Your Edited Code

First, setup ups and make sure you have the products needed by nutools,

source $EXTERNALS/setup

where $EXTERNALS points to the location of the necessary external products for ART and NuSoft. At Fermilab, $EXTERNALS is typically in /grid/fermiapp/products/<experiment>/. For NOvA, the area is /grid/fermiapp/products/nova/externals.

Then, create a build directory,

cd some_working_dir
mkdir nutools_build

and an install directory

mkdir nutools_install

NB nutools_build and nutools_install are suggested names for the build and install directories, you can choose whatever you like.

Then, setup the build

cd nutools_build
source ../nutools/ups/setup_for_development -d (or -p)

The -d option is for a debug build, the -p option is for a prof build. This step sets up the products and establishes the environment.

buildtool -I /full/path/to/nutools_install -b -i

Test Your Build

You will want to test your freshly compiled libraries to be sure they work as expected. To do so, you should really develop test modules that can be run using just ART and put those into a test subdirectory for the package you are editing. If you don't have one of those already, log into your experimental gpvm node from a fresh terminal and setup for your experiment. That will setup the public version of nutools.

You want to be able to use your private version. First copy the .upsfiles directory from /nusoft/app/externals directory into your nutools_install directory

cp -R /nusoft/app/externals/.upsfiles nutools_install

Then un-setup the public version of nutools and add your nutools_install directory to the PRODUCTS environmental variable

unsetup nutools
export PRODUCTS=/full/path/to/nutools_install:$PRODUCTS

It is better if you have not setup your experiment specific code.

Finally, setup your new copy of nutools

setup nutools vX_YY_ZZ -q <build base>:<build type>

where vX_YY_ZZ is the current nutools version and <build base> is the same as the art <build base> you are building against and <build type> is either debug or prof.

The necessary environmental variables have now been set for you to use your local version of nutools.

You will need to rebuild any packages that depend on the NuTools code and run a test job.

The dependencies for nutools are defined in the ups/product_deps file.

Trouble Shooting

If you have an error of the form

ERROR: Version conflict -- dependency tree requires versions conflicting with current setup of product XXX: version vA_B_C vs vD_E_F

That error means that the version of nutools checked out into your private area is set to look for version A_B_C of the external product XXX (i.e. art, genie, etc) and you have already setup version D_E_F. Try an unsetup of the product

unsetup XXX

Then try setting up nutools again.

Committing From A Read-Only Checkout

If you have a read-only checkout and need to commit code, please contact Brian Rebel, , to get permission to check your code in. Once you have permission, cd to the appropriate package <PACKAGE> in your nutools directory and do

svn switch --relocate https://cdcvs.fnal.gov/subversion/nusoftart/nusoftsvn/trunk/<PACKAGE> \
svn+ssh://p-nusoftart@cdcvs.fnal.gov/cvs/projects/nusoftart/nusoftsvn/trunk/<PACKAGE>

Then you can check in the code.

Tagging a Release and Building the UPS Product Files - Experts Only

NB Do not attempt to tag a release and build new product files without explicit permission from Brian Rebel.

First check that the code compiles and runs as expected. Then you need to update the version number in

infrastructure/bootstrap.sh
infrastructure/built_nutools.sh
nutools/ups/product_deps

to X.YY.ZZ and the value is determined by the previous tag. If you are adding functionality or tagging for a new release of ART, you want to update the minor version number, ie YY. If you are making a patch, update the ZZ.

The version is on the "parent" line of product_deps. You will also need to update the versions for the products that nutools depends on in the product_deps file as well. Once those updates are done, you can should commit them to the repository. Then do

svn copy -m"some comment" 
         svn+ssh://p-nusoftart@cdcvs.fnal.gov/cvs/projects/nusoftsvn/trunk
         svn+ssh://p-nusoftart@cdcvs.fnal.gov/cvs/projects/nusoftsvn/tags/X.YY.ZZ
To build a tagged release:
  1. Identify a local product directory
  2. cd infrastructure
  3. ./bootstrap.sh <local product directory>
    This creates nutools-<dot version>-source.tar.bz2 and nutools/<ups version> in <local product directory>
  4. cd <local product directory>/nutools/<ups version>
  5. setup ups (from anywhere)
  6. ./build_nutools.sh <local product directory> <base qualifier> <debug|prof> [tar] >& <logfile> &

If you specify "tar", then nutools-<dot version>-slf5-x86_64-<qualifier list>.tar.bz2 will be built in <local product directory>