Advanced Release Setup (Optional)

Last update: 23 Aug 2023 [History] [Edit]

This section shows how to perform two advanced release setup options. These are not required as part of the tutorial but could be useful for future reference.

Building your own Analysis Release

In some situations it can be helpful to build your own release, most commonly because you are working on a machine without access to cvmfs. Actually building a local release can take a while, but it is very straightforward to do (assuming you have cmake installed):

RELEASE_DIR=/...
mkdir release_build
cd release_build
git clone https://:@gitlab.cern.ch:8443/atlas/athena.git
cd athena
git checkout release/
cd ..
./athena/Projects/AnalysisBase/build_externals.sh -c
./athena/Projects/AnalysisBase/build.sh -a -c -m -i
mkdir $RELEASE_DIR
mv ./build/install/* $RELEASE_DIR/

tip Building a release is a lot faster if you do it on a local disk instead of a network disk, as the release consists of a large number of small files. On most machines /tmp/ will be a local disk even if all the user disks are located on file servers.

tip The instructions above will install a numbered release, which should be your default to work with. If you want to use the absolutely latest, bleeding edge version you can replace release/ with 25.2.

warning Note that with the newer versions of macOS (with the latest version of Xcode installed) you’ll have problems compiling older releases. And unfortunately some numbered releases (like 21.2.36 for instance) don’t build on macOS at all.

To set up this new release just do:

source $RELEASE_DIR/AnalysisBase/*/InstallArea/x86_64-*/setup.sh
cd ../build
source x86_64-*/setup.sh

Note that you don’t actually need a variable $RELEASE_DIR I just used that in this example to make sure we use the same directory everywhere.

If you want to build another (updated) release, you don’t need to checkout the repository again (which is rather slow). Instead it is sufficient to do instead:

cd athena
git pull
cd ..

Use a Docker analysis release image

Another option to compile/run your code is within a docker image containing that release. There are a lot of pros and cons to this, which we won’t discuss here. If you are doing this as part of the software tutorial week there will be a dedicated session for Docker as well. This is just the brief/short how-to for using them.

You normally start out by downloading the docker image for the release you want (not strictly necessary, but good practice). The docker images get managed by docker behind the scenes (details in the docker session), so you don’t have to worry about that yourself:

docker pull atlas/analysisbase:

tip These instructions will use a numbered release, which should be your default to work with. If you want to use the absolutely latest, bleeding edge version you can replace atlas/analysisbase: with atlas/analysisbase or atlas/analysisbase/latest.

Next you should start up a container from that image, using a command like this:

docker run --rm -it -v $PWD/source:/home/atlas/source -v $PWD/build:/home/atlas/build atlas/analysisbase: bash

There are a lot of things to this command, but just to point out the most important ones:

  • -it ... bash starts an interactive session, i.e. one in which you can actually type commands into a shell.

  • -v .../... makes directories on your machine available inside the container.

  • These instructions assume you are in the directory containing source and build. If you are in a different directory replace $PWD with the absolute path to that directory (i.e. starting with /).

  • We map both the source and the build directory into the container. You should normally keep your source directory outside of the container, but you can keep the build directory completely in the container. All you have to do is leave out the second -v option, and then create the build directory when you get into the image, and rerun cmake every time.

Then inside the container you need to set up your release and build directory:

source setup.sh
cd build
cmake ../source
source x86_64-*/setup.sh 
make

Or if you already initialized the build area just do:

source setup.sh
source build/x86_64-*/setup.sh

warning You should keep your build directory separate between docker and native builds, and you should also create a new build directory for each release. Or, as indicated above, you may just opt for recreating the build directory each time, which avoids such problems.