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 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 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.
-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
asetupsomeplace other than your
builddirectory, you also need to remove
asetupagain 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