Difference between revisions of "Building the Analyzer and BigBite libs from CVS (d2n)"

From Hall A Wiki
Jump to: navigation, search
m (Here's how I set-up an analyzer on my debian 'Lenny' distribution)
(Updated with CVS upload instructions)
Line 1: Line 1:
=== Here's how I set-up an analyzer on my Debian 'Lenny' distribution ===
+
== Here's how I set-up an analyzer on my Debian 'Lenny' distribution ==
 
   I use bash and vim like all right-minded people :-p
 
   I use bash and vim like all right-minded people :-p
 
   The Transversity wiki also has lots of good info:
 
   The Transversity wiki also has lots of good info:
Line 49: Line 49:
 
         script in $HOME/bin and then source it in my .bashrc.
 
         script in $HOME/bin and then source it in my .bashrc.
  
=== Some Miscellaneous config instructions ===
+
== Some Miscellaneous config instructions ==
 
* Configure env variables to point to ROOT, etc
 
* 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
 
   If you're not on a JLab CUE system, you may need to edit and source the the
Line 60: Line 60:
 
   #include <stdlib.h>
 
   #include <stdlib.h>
 
   This fix is in the 'd2n' CVS branch.  (22 June 2009, BDS)
 
   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
 +
 +
*Check out [[Off Line Analysis for transversity#CVS .28Concurrent Versions * System.29|Transversity:CVS Help]], or ask Brad.

Revision as of 17:30, 25 June 2009

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
 % ./pull_cvs
  • 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/*):
  1. 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.)
  2. 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.
  3. 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