Setup UbooneCode Enviroment - twongjirad/LArLiteSoftCookBook GitHub Wiki
the answer
source /cvmfs/uboone.opensciencegrid.org/products/setup_uboone.sh
ups list -aK+ uboonecode
setup uboonecode [version] -q [qualifier]
mkdir myubcode
cd myubcode
mrb newDev
source localProducts_larsoft_[version]_[qualifier]/setup
cd srcs
mrb g uboonecode
cd uboonecode
git checkout -b [branch name] [version]
mrbsetenv
cd .. (or from anywhere)
mrb i
where [version] looks something like v06_34_01 and [qualifier] looks like e14:prof. [branch name] is the name of the branch you'll park your changes to uboonecode. It should have the following pattern: feature/[fnal username]_[one or two word description of the code you are writing].
annotated instructions
setup the UPS system
source /cvmfs/uboone.opensciencegrid.org/products/setup_uboone.sh
This setups up your shell to have the environment variables necessary to use the UPS system, which allows one to quickly setup pre-built packages on the Fermilab system.
print out a list of uboonecode versions
ups list -aK+ uboonecode | sort
note that by piping | the output of ups list to the unix sort command, the version at the bottom should be the latest tagged version.
setup a uboonecode environment your version of choice
So, setup the version you desire. for this example using "v06_34_01" with qualifier "e14:prof". You'll find that the version updates a lot. Note that the qualifier tells us something about the build environment employed. For example, which version of the gcc compiler is used.
setup uboonecode v06_34_01 -q e14:prof
you'll see a number of environment variables now setup in your shell that point to the proper version of uboonecode and the various larsoft dependencies. if you're curious check them out using
export | grep -iI uboonecode
export | grep -iI larsoft
it's a lot of environment variables.
At this point, you've setup a proper uboonecode/larsoft runtime environment for the version you specified. You could run the larsoft event loop using
lar -c [fcl file] -s [input larsoft art file]
setup a uboonecode build environment
But almost always, we are interested in more than just running larsoft. We are trying to develop some algorithm or run an analysis. To do this, we need a build environment. This consists of a set of directories where we have access to source code we can modify or add to along with the proper environment where we can build that code and run it using the proper dependencies.
To start a new build environment, make a new directory for your copy of uboonecode
mkdir myubcode
cd myubcode
make a new mrb environment
mrb newDev
you'll see something like
>$ mrb newDev
building development area for larsoft v06_34_01 -q e14:prof
MRB_BUILDDIR is /uboone/app/users/tmw/dev/v06_34_01/build_slf6.x86_64
MRB_SOURCE is /uboone/app/users/tmw/dev/v06_34_01/srcs
INFO: copying /grid/fermiapp/products/larsoft/larsoft/v06_34_01/releaseDB/base_dependency_database
IMPORTANT: You must type
source /uboone/app/users/tmw/dev/v06_34_01/localProducts_larsoft_v06_34_01_e14_prof/setup
NOW and whenever you log in
This created a bunch of directories which you can look at using
>$ ls
build_slf6.x86_64 localProducts_larsoft_v06_34_01_e14_prof srcs
As you might image, src is source code goes. build_slf.x86_64 is where the output of compilation goes. Finally, localProducts_... is where the "installation" or "release" is. To get the shell to point to this location and setup this build environment do the following
source localProducts[...]/setup
checkout some source code
Though the build environment is now created, we still need some source code to modify. The next step is to checkout some code. (Note that if you are only running programs and note developing) you can skip this and the next step.)
cd srcs
mrb g uboonecode
TIP: make sure you're kerberos ticket is still valid. This way you will be given permission to push your changes back into the repository.
kinit [fnal username]@FNAL.GOV
If you want to check the status of your kerberos ticket do
klist
Checking out the right version
So, by default, mrb g uboonecode will checkout the uboonecode repository and leave you at the HEAD of the develop branch. This is the latest and greatest. Usually what you want to do is to fork from your known version, make some changes, test it out, then push back into the repo. Now, you do not want to check into the develop branch without first making sure your code can build and operates appropriately. At the same time, you want to share your code with others via the repository. We resolve this tension by making a new feature branch that is tracking a tagged version.
cd uboonecode
git checkout -b feature/[your username]_[short one or two word description of your new code] v06_34_01
Let's break down this command. git checkout gets source code from the repository. We use the -b flag to tell git to checkout the code into a new branch. In principle, you can call this branch whatever you want. But we try to use the git flow pattern (google it) on MicroBooNE, so we use the above convention for branch names. Finally, the last part of the command v06_34_01 is just the tag name. We want to start our new branch on a tagged version of the repo. This way we can update the repo. (git pull) without updating our copy of the source code. Since things change so much, within a week, the HEAD of develop will refer to a new tagged version and your build environment will likely become all out of sync with larsoft dependencies.
However, at some point you will need to sync up with develop. When that time comes, you can merge your changes to develop, by using (from the src/uboonecode folder)
git checkout develop
git pull
git checkout feature/[your username]_[your branch name]
git merge develop
The first command switches branches to develop. (Remember to commit your code first before switching). The second command updates your local copy of the repository and updates the source code to the current state of develop. The third command brings you back to your branch. The fourth command merges the changes in develop into your branch.
Finally, setup your build environment
To finish setting up the build environment
mrbsetenv
You should see a message like:
[ tmw@uboonegpvm04 uboonecode ]$ mrbsetenv
The working build directory is /uboone/app/users/tmw/dev/v06_34_01/build_slf6.x86_64
The source code directory is /uboone/app/users/tmw/dev/v06_34_01/srcs
----------- check this block for errors -----------------------
----------------------------------------------------------------
Hopefully the error block is empty!
Now, the build environment is setup and ready to go.
NOTE if you want to come back and setup this build environment, source the setup script above and type mrbsetenv.
Build and installing the code
build (and install) the checked out code (or the code you've modified). You can determine the number of cores used to build the code after -j.
mrb i -j4
Get coffee, this is going to take awhile.
Next time to reload this environment
source /cvmfs/uboone.opensciencegrid.org/products/setup_uboone.sh
cd myubcode
source localProducts*/setup
mrbsetenv
Note, that by default, when you check out a new copy of uboonecode (the 'mrb g' command above), you are placed on the develop branch. If you want to checkout a specific tagged version of uboonecode, then checkout this page.