It is likely that in the course of your analysis development you will need to update to use a newer version of the Analysis Release. It can be very easy to do this (of course this comes with caveats, especially if you have manually checked out specific package tags, and/or made modifications to those packages).
If you want to update to a newer Analysis Release, you should start a new shell on the machine (e.g. by logging out and logging back in), so that you get a clean environment. Before you setup a new release you need to stop and think a bit ….
Other issues to be aware of is the possibility the tools you are using in your analysis code have changed (if the packages are different between the old and new release).
Also, before you follow the instructions below: Did you store any
files in the
build directory that you may want to back up first?
As mentioned before, you shouldn’t really store anything in the
build directory that you want to keep, but better double check to
Did you pass any extra parameters to cmake when you created this
build directory, e.g.
-GNinja? If so,
you probably want to add them to the
cmake call in the
instructions below as well.
Second, assuming the points above are not issues, you can simply remove and re-create the build area as usual, find packages, and re-compile. If you wanted to update to AnalysisBase 9.9.99 (which doesn’t actually exist), you would do:
cd .. rm -rf build mkdir build cd build asetup AnalysisBase,9.9.99 cmake ../source/ source x86_64-*/setup.sh make
As mentioned before, some users like to keep multiple build
directories around so they can test the new release before getting rid
of the old build directory, in which case you’d probably name your
build directory something like
build-9.9.99 to indicate the release
In the past we had instructions that re-used the build directory when changing releases, but there are a number of things that can go wrong with it and if something goes wrong the first piece of advice will usually be to remove and recreate the build directory. Actually we may also give you these instructions for a number of other possible build problems. Since there are very few upsides to not re-creating the build directory when changing releases you may just as well do that by default.
Sometimes you will need to change the versions of individual packages to a version that is not yet in a release. But before you do that you should double check whether there is a nightly build that already has that version of the package installed. A nightly build is like a numbered release, except that it will be deleted after about a month. Still it is preferable to checking out and compiling release packages locally, and there will be a numbered release with that package before the nightly gets deleted.
If there is no nightly you can use, you first need to clone the repository:
cd ../source git clone [...].git athena
[...] here should be replaced with the actual URL for that
repository. If you don’t know the URL go to GitLab, which has a field
that you can copy and paste into your shell. You may also have to go
into the repository to checkout the specific branch you need
Next you need to create a
source/package_filters.txt file that lists
the packages you want to keep:
+ athena/PhysicsAnalysis/D3PDTools/EventLoop - athena/.* + .*
If you followed the offline git tutorial it will tell you that you should not put the
package_filters.txtfile inside your athena repository so that you don’t commit it by accident. However since in this case our case the source directory is not the same as the athena repository it is safe to put it there. Indeed in the analysis git tutorial we will show you how to use submodules to control the exact version of the athena repository that gets checked out and then it is handy to have the pre-made
package_filters.txtinside your source directory to select the exact packages you want from it.
Now you have to run cmake somewhat differently to tell it which packages to compile (otherwise it will just compile everything in the athena repository which would not only be very slow, but also fail):
cd ../build cmake ../source
If you followed the offline git tutorial you may think this ought to be
cmake -DATLAS_PACKAGE_FILTER_FILE=../source/package_filters.txt ../source
And indeed the two do exactly the same. If you don’t specify a location for the
package_filters.txtfile and it finds one inside your source directory it will use that instead.