Building the Analyzer and BigBite libs from CVS (d2n)
From Hall A Wiki
Here's how I set-up an analyzer on my Debian 'Lenny' distribution
I use bash and vim like all right-minded people :-p The Transversity wiki also has lots of good info: Off Line Analysis for transversity
- Install ROOT (if you haven't already)
% apt-get install root-system
- Download and build the analyzer and the d2n replay code
% mkdir d2n_analysis % cd d2n_analysis % wget -nd http://www.jlab.org/~brads/hacks/pull_cvs % chmod a+x pull_cvs
- This script sets the appropriate CVS variables and pulls the d2n/ and analyzer/ branches
- You should now have two new directories
% ls -F analyzer/ d2n/ pull_cvs*
- Copy and edit the root-setup.sh file. You should update the 'd2n' path at least. 'd2n' needs to point to the directory that you called ./pull_cvs from (ie. which contains the 'analyzer/' and 'd2n/' directories.
% cp d2n/root-setup.sh . % vim setup.sh
- Source the file to set the environment variables
% source root-setup.sh
- Build the base analyzer
% (cd analyzer && make)
- Build the BigBite and replay code
% (cd d2n && ./makeall)
- Now move into the default replay directory
% cd d2n/replay/
- Set up symlinks
The following directories should all be replaced with symlinks summaryfiles/ ScratchROOTfiles/ ROOTfiles/ that all point to an appropriate work disk that is NOT in your $HOME directory. (Your sys-admin and backup software will thank you for it.)
- Now you should be able to run the analyzer as you normally would
NOTE: The environment variables in 'root-setup.sh' need to be set properly or the analyzer will not work. I put the script in $HOME/bin and then source it in my .bashrc.
Some Miscellaneous config instructions
- Configure env variables to point to ROOT, etc
If you're not on a JLab CUE system, you may need to edit and source the the 'root-setup.sh' file. The settings in the file work for my debian 'lenny' distribution. YMMV.
- Problem building the BigBite specific libraries in the transversity/ branch
If you see a 'atoi' undefined error when compiling bigbitelib then add the following line to the include list in 'BBDecData.cxx' and recompile. #include <stdlib.h> This fix is in the 'd2n' CVS branch. (22 June 2009, BDS)
What to do to upload changes to the CVS
Step 1: Integrate your 'test' files into the standard analyzer structure
- For example, for changes to the database ($DB_DIR/*):
- Start with a clean CVS version of the analyzer and install your updated *.dat files to the correct time-stamped directories in $DB_DIR/. It is critcally important that you test any updates going to CVS using a fresh analyzer package that has been minimally modified by your personal config (*especially* test *.dat DB files in the analyzer directory that would take precedence over the ones in $DB_DIR.)
- Now replay enough runs using that analyzer to make sure it is automatically finding the correct, updated, DB file for any given d2n run period (ie. using the timestamp keys). Collaborators should be able to pull the CVS copy and be confident that it will work as expected -- it's up to you to make sure your changes function before pushing them upstream.
- Note that you will likely be pulling the CVS version yourself weeks or months down the line to get updates/fixes applied by others. You don't want to worry about re-applying your own older fixes and updates either.
Step 2: Send Brad your updated files
- If it's a few files, you can just email them with an indication of what files they are replacing (full path please).
- If it's a whole bunch of changes, then you can generate a diff and send that:
% cvs diff -u [files and/or directory...] > $HOME/analyzer.patch
- For example, if you have a bunch of updates scattered across the 'd2n/DB/' directory try this:
% cd d2n % cvs diff -u DB > $HOME/analyzer_db.patch
- Check out Transversity:CVS Help, or ask Brad if you have problems