How to update to a different release (Advanced/Optional)

Last update: 17 Nov 2024 [History] [Edit]

warning This section refers to the directory structure discussed later in this tutorial in the Workarea setup section.

It is likely that in the course of your work you will need to update to use a newer version of the 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 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 set up a new release you need to stop and think a bit:

  • You may have checked out additional packages on top of the previous release you were using (not including your own package(s)):
    • Do you still need a local setup of those additional packages?
    • Did you make any local changes to those packages?
    • How will the version of those packages be different in the newer release?

  • The tools you are using in your code may have changed (if the packages are different between the old and new release). You should be on the lookout for compilation and configuration errors with the new release.

  • Did you store any files in the build directory that you may want to back up first? You shouldn’t really store anything in the build directory that you want to keep, but better double check to be safe.

  • Did you pass any extra parameters to cmake when you created this build directory, e.g. -DCMAKE_BUILD_TYPE=XYZ or -GNinja? If so, you probably want to add them to the cmake call in the instructions below as well.

tip You might want to join the atlas-sw-pat-releaseannounce@cern.ch mailing list, where new Analysis Releases are announced, along with the relevant updates to that release.

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), from your main area you would do:

rm -rf build/*
cd build
asetup AnalysisBase,9.9.99
cmake ../source/
source x86_64*/setup.sh
make

tip If you previously called asetup someplace other than your build directory, you also need to remove .asetup.save and call asetup again in that location.

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 used.