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 ….
Other issues to be aware of is the possibility the tools you are using in your 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?
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.
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), 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
If you previously called
asetup
someplace other than yourbuild
directory, you also need to remove.asetup.save
and callasetup
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.