A guide to building MINOS releases in the 64-bit (SLF6+) era.

In this new regime the plan is to leach off leverage the infrastructure provided by the lab for other experiments. This means using releases and builds of base products such as gcc, ROOT, libxml, pythia6, log4cpp, geant4 and such that are provided for them, and focus on building only those specific to MINOS (minos_offline code and the version libsigc++ required by it).


Use of SRT

MINOS uses SoftRelTools to manage code check-out structure and build releases.

Use of UPS

The plan is to make use of as many existing UPS products as possible. And when feasible to not duplicate installations that exist for other experiments. Ideally we'll do this in a way that makes it simple to use CVMFS as well. To that end, MINOS will have two (modern Linux64bit) UPS areas:

  • /grid/fermiapp/minos/minossoft_srt_64bit/minos_ups_products
    • minos_offline -- tables to setup externals, and source srt setup
    • minos_config -- ENV_TSQL_USER, ENV_TSQL_URL ...
    • libsigcpp -- MINOS specific v1_2_7 builds
  • /grid/fermiapp/products/minos/externals
    • any other necessary UPS products (gcc, ROOT, ... etc)

Other UPS areas:

  • /grid/fermiapp/products/common/db -- used to bootstrap UPS and ifdh (gets us the latest UPS, etc)
  • /grid/fermiapp/products/nova/externals -- alternative source for gcc, ROOT, ... etc
  • /grid/fermiapp/products/larsoft -- similar


The two areas that MINOS manages are:

which should map to:

Coupling of MINOS setup script, SRT and UPS.

The MINOS setup script attempts to simplify the user experience (vs. bare UPS). Notice that the MINOS-specific UPS area live under the $SRT_DIST area. This should allow for the simple CVMFS mapping without symlinks (by keeping positions relative). UPS is responsible for setting up environment variables, while the setup_minos scripts front-ends that (bootstrapping UPS, dealing with arguments, etc)

setup_minos () 
    source $MINOS_SETUP_DIR_GRID/ $*
$ setup_minos --64bit
Usage: setup_minossoft [-O|-o] [-r release] [-q upsqual] 
  -h:      this helpful message                      
  -v:      increase setup script verbosity           
  -l:      list possible versions                    
  -r arg:  release [default "development"]         
  -q arg:  UPS qualifier (e.g. "e9:r5")              
  -O:      minossoft built with optimizer (SRT_QUAL=maxopt) 
  -o:      optimized ROOT, unoptimized minossoft     
  --64bit  64-bit (new)                              

Expert only:                                         
  -c arg:  created script flavor (csh,sh)            
  -K:      keep script                               
  -P:      print script                              
  -D:      toggle send datagram  

Actual Step-by-step

Do these as minsoft:

  # log into a SLF6 (or someday SLF7) machine as "minsoft" 

  # bootstrap
  source ~/shrc/
  # equivalent to defining
  #   function setup_minos () 
  #  { 
  #      MINOS_SETUP_DIR_GRID=/grid/fermiapp/minos/minossoft/setup;
  #      source $MINOS_SETUP_DIR_GRID/ $*;
  #      export
  #  }

  # get some environment setup
  setup_minos --64bit

  # determine dk2nu & geant4 versions to use (see below)  
  # we'll use <release> for the MINOS release version, e.g. "development" or "R3.01" 
  # and <quals> for "e9:r5" (<qualswithdash> = "e9-r5")

  cd /grid/fermiapp/minos/minossoft_srt_64bit/minos_ups_products/minos_offline
  ./make_minos_offline_ups_skeleton <release> <quals>

  # edit the table file
  emacs <release>/<upsflavor>/<qualswithdash>/ups/minos_offline.table

  # make sure that it is setting the right _version_ of dk2nu and geant4 (already chose qualfiers)
  # make sure that MINOS_CXX (probably "GCC_4_9") reflects what would get setup
  # note that there are _three_ instance that have to be updated if any instance

  setup_minos --64bit -r <release> -q <quals>

  # if that gave errors check below for suggestions, don't proceed

  # check out the source packages
  msrt -e release -R -r <release>

  # check that include symlinks are okay
  ls -l | egrep  "/[A-Za-z]*/" 

  # should look something like:
  # lrwxrwxrwx 1 minsoft e875 32 Jan  9 17:11 PackageMaintenanceSupport -> ../PackageMaintenanceSupport/src
  # lrwxrwxrwx 1 minsoft e875 23 Jan  9 17:05 SoftRelTools -> ../SoftRelTools/include
  # lrwxrwxrwx 1 minsoft e875 20 Jan  9 17:13 UserManualDoc -> ../UserManualDoc/src
  # if it has any other packages listed (generally it seems "FCPCFilter" fails frequently,
  # and is set to "../FCPCFilter/FCPCFilter" instead of simply "../FCPCFilter") then correct the linkage 

  # build debug version
  setup_minos --64bit -r <release> -q <quals>
  nohup msrt -e -l build -r <release> > build_debug.log 2>&1 &

  tail -f build_debug.log
;;;;; [wait for that to finish ...]
  count_buildlog_warnings --dow <day-of-week>  # eg. Mon Tue Wed ...

  # don't freak out about any of the following packages failing to build:
  #     DocBuilder
  #     Midad
  #     TriD 
  # for now we'll ignore that we have no graphic displays
  # build maxopt version
  setup_minos --64bit -r <release> -q <quals> -O
  nohup msrt -e -l build -r <release> > build_maxopt.log 2>&1 &

  tail -f build_maxopt.log
;;;;; [wait for that to finish ...]
  count_buildlog_warnings --dow <day-of-week>  # that the build started

  # if there was an error then see below for possible fixes

Product versions

MINOS will key off of dk2nu and geant4. Between these two products all the remaining dependent products are pulled in. It is critical that these are build consistently.

Why our own libsigc++?

MINOS code was written against the v1_2 series of the external product. Quite some time ago the owners essentially redesigned / refactorized the code in the v2 series. This was done in a completely incompatible manner and MINOS code can not be built against that series without MAJOR re-writes. As the code still works as-is and there is no manpower to make the transition, MINOS will stick with the last version v1_2_7.

So this only needs to be built when there are new qualifiers (especially if there is a new compiler version).

What to do when there is a new compiler in the stack

Hopefully, tests of new software stacks get tried in "development" first. So proceed along the lines of:

  cd ${SRT_PUBLIC_CONTEXT}/SRT_MINOS/SoftRelTools/compilers/
  cp  GCC_<X>_<Y>.mk
  # make any necessary modifications to the file
  # make it so one can commit from this directory
  minos_cvs_migrate ssh
  cvs add GCC_<X>_<Y>.mk
  cvs commit -m "options for new compiler version" GCC_<X>_<Y>.mk
  minos_cvs_migrate pserver
  # the last ensures that the this checked out directory can be updated by the nightly build

Proceed to the next sub-section as a new compiler will (should!) always mean an new "qualifier".

What to do when there is a new "qualifier"

A change in the qualifier probably means a new version of libsigc++ needs to be built. You'll probably get a message similar to:

$ setup_minos_64bit --64bit -r <release> -q <quals>
ERROR: Action parsing failed on "unsetuprequired(libsigcpp)" 
ERROR: Found no match for product 'libsigcpp'
ERROR: Action parsing failed on "SetupRequired(libsigcpp v1_2_7 -q debug:<quals>)" 
srt_setup SRT_BASE_RELEASE=<release> SRT_CXX=<dashquals> SRT_QUAL=debug
MINOSSOFT release "<release>" 
SRT_SUBDIR=Linux2.6-<dashquals>-debug ROOT=Linux64bit+2.6-2.12-<quals>-nu-debug CONFIG=v02
  # make sure that the proper compiler _is_ setup
  # it should be consistent with the <quals> that other packages are using
  # specifically it will check vs GENIE unless overridden
  cd /grid/fermiapp/minos/minossoft_srt_64bit/minos_ups_products/libsigcpp
  ./make_libsigcpp127  <quals>
  # e.g.  ./make_libsigcpp127 e9:r5