Rebuilding after upgrades - SyneRBI/SIRF GitHub Wiki

You may need to re-build if things go wrong during installation, after an operating system/package upgrade, or when newer versions become available. (One particular example is when you upgraded your boost version). It can be difficult to know what shortcuts are safe when re-building and it can overall be faster to start from the beginning. General tips include:

  • Finish any OS updates first.
  • For Mac OS users using brew, run brew update then run brew doctor and act on its suggestions if necessary. For the ISMRMRD and Gadgetron dependencies that were installed using brew, you can use brew upgrade instead of brew install to update.
  • Update from the Git repositories.
  • Remove your old install directory, or at least install/include/. (This is due to https://github.com/SyneRBI/SIRF/issues/659)
  • Empty the build directories for the various stages to force a proper re-build. Otherwise, not all changes and dependencies may be detected, leading later to inconsistencies.

Rebuild with the SuperBuild with new versions of dependencies

When you want to rebuild SIRF using a different version of a dependency (e.g. when going to a new release of SIRF), the safest option is to start from scratch, i.e. either build and install in different places, or remove the build and install directories.

Advanced usage

If you want to keep (some of) your CMake settings for the SuperBuild, you can do that by only removing the builds directory where you build the SuperBuild). You might still need to remove your installed include files as well as installed lib/cmake. Then you must either

  1. modify the version_config.cmake to match the version you want,
  2. issue cmake forcing it to remove other relevant cached variables using -U<variable_name>

or

  1. set the relevant TAG by hand with CMake (e.g. cmake -DSTIR_TAG:STRING=origin/master ...).

For instance, the following is the command used in the creation of the VM:

cmake ../SIRF-SuperBuild -DCMAKE_INSTALL_PREFIX=${SIRF_INSTALL_PATH} \
  -USIRF_URL -USIRF_TAG -USTIR_URL -USTIR_TAG -UGadgetron_URL -UGadgetron_TAG -UISMRMRD_URL -UISMRMRD_TAG \
  -DUSE_SYSTEM_SWIG=On -DUSE_SYSTEM_Boost=On -DUSE_SYSTEM_Armadillo=On -DUSE_SYSTEM_FFTW3=On -DUSE_SYSTEM_HDF5=ON

(you can reset all tags by using -U*_TAG)

Why is this so complicated?

  • Setting include/link paths is tricky for a build with many dependencies, especially as some of our dependencies do not install versioned files.
  • Many include files, such as boost files, are usually included as system files, and CMake does not check for changes in system include files (they recommend rebuilding everything when upgrading your system).
  • CMake remembers various settings to speed-up future builds.