Release Setup

Last update: 16 Aug 2024 [History] [Edit]

Use a Docker 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 gitlab-registry.cern.ch/atlas/athena/analysisbase:22.2.110

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 gitlab-registry.cern.ch/atlas/athena/analysisbase:22.2.110 with gitlab-registry.cern.ch/atlas/athena/analysisbase or gitlab-registry.cern.ch/atlas/athena/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 gitlab-registry.cern.ch/atlas/athena/analysisbase:22.2.110 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 release_setup.sh
cd build
cmake ../source
source x86_64-*/setup.sh 
make

Or if you already initialized the build area just do:

source release_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.

More details about Docker can be found here.