[CCPPETMR/CCPPETMR_VM] handle SIRF versions in update_VM.sh (#26)
Kris Thielemans
We currently use master for most clones (except ismrmrd since 29a4ee2). Ideally we'd be able to differentiate between an update and an upgrade (like apt-get) or so.
This will likely have to be done in conjunction with the SuperBuild (see #25)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Edoardo Pasca
How much configurable must the update script be?
Currently the SuperBuild allows DEVEL_BUILD option and ISMRMRD, Gadgetron, SIRF and STIR URL/TAG definitions.
Kris Thielemans
the update script doesn't have to be configurable at all.
we can switch to DEVEL_BUILD outside of the update script (like we do with the STIR full build), i.e. in effect we run cmake again. once that's done, future updates will stick to the same CMake settings
Kris Thielemans
this needs more thought. Our aim is to rebuild the VM in a known state from the vagrantfile. However, this uses update_VM.sh and therefore currently gets the SuperBuild/master. It is therefore not tied to a SIRF version.
It seems to me that at least at VM-build time, we need to stick to the superbuild tag derived VM_version.txt or something.
Possibly we could give update_VM.sh an optional argument which defaults to the latest release (e.g. via git fetch;git describe --abbrev=0 --tags --match=v* (see https://stackoverflow.com/questions/4277773/how-to-get-latest-tag-name). In the Vagrantfile, we can then set the optional argument to what is in VM_version.txt. I think that'd mean that we can checkout a CCPPETMR_VM-tag and recreate the VM (of course without the manual steps done afterwards).