- Table of contents
- Developing NuTools Code
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://firstname.lastname@example.org/cvs/projects/nusoftart/nusoftsvn/trunk/nutools
svn co http://cdcvs.fnal.gov/subversion/nusoftsvn/trunk/nutools
Instructions for committing changes from a read-only check out are below.
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,
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
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.
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
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, email@example.com, 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://firstname.lastname@example.org/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://email@example.com/cvs/projects/nusoftsvn/trunk svn+ssh://firstname.lastname@example.org/cvs/projects/nusoftsvn/tags/X.YY.ZZTo build a tagged release:
- Identify a local product directory
- cd infrastructure
- ./bootstrap.sh <local product directory>
This creates nutools-<dot version>-source.tar.bz2 and nutools/<ups version> in <local product directory>
- cd <local product directory>/nutools/<ups version>
- setup ups (from anywhere)
- ./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>