During today’s confab meeting (notes), we decided to update the minimum required CMake version in ITK master from 2.8.12 to 3.8.2. The change will occur at the end of next week. Meanwhile, all dashboard build machines need to have their CMake upgraded to 3.8.2 or newer.
The plan it to switch the C++ standard to 11 the week after that. This is part of big changes of version 5.
Thank you bringing this update to my attention, @dzenanz
One of the ITK dependent projects I’m involved with, https://github.com/SuperElastix/SuperElastix still has CMake 3.5.1 on the continuous build machine (running gcc-5.4.0 on linux). Are you planning to use some specific CMake features that are not yet available in CMake 3.5.1?
CMake 2.8.12 was released in Oct 2013, so the requirement upgrade looks fair to me to make ITK an even more modern toolkit.
I guess we’ll need to grep for all cmake_minimum_required(VERSION 2.X) appearances (e.g. examples, remote modules, etc.), and change them.
Also potential references to the CMake minimum version in the SW Guide.
Is this already being addressed or shall I take this on me for the SW Guide, then the examples, then see if it all goes OK with the latter, and then try the remote modules?
As discussed at the confab, we should use the version available with the Ubuntu Long-Term-Support distribution at the time of the release (this will be 18.04 - Bionic Beaver). This version is currently CMake 3.9.5. It may change in the future. Since Windows developers download the latest version from cmake.org and macOS developers download from cmake.org or use Homebrew (which tracks latest CMake), there is not a reason to use a lower version in these cases.
Our previous conversations have resulted in agreement that CMake 3.8.2 would be the require version. If there is a feature/bug encountered that requires a newer version of CMake we could consider a newer version. I am not sure what to install on my systems now, with the confusion.
I am not sure why just Debian/Ubuntu would dictate the version of CMake required. Centos/Redhat is also a very popular flavor of Linux, but they only have 3.6.3 available in the EPEL. And these Linux flavors usually have the longest running support. There are easy options to get newer versions of CMake installed on Linux systems too. Again, I am confused on this proposed specification/requirement.
No, we agreed to use the version released with Ubuntu 18.04. See the notes from the 2017-12-08 discussion. This was also the discussed approach on 2018-01-12.
Newer CMake versions generally contain more bug fixes. We should use the latest version of CMake available, which has the most bug fixes and the most features, that is not burdensome for developers to obtain.
Install the latest released version of CMake, 3.10.1.
Other versions of Linux should be considered, also. Ubuntu is the most popular developer edition, so it holds a lot of weight.
3.6.3 is below the required 3.8.2 for good C++11 support, so it should not be used as a minimum version since we are moving to C++11.
If I read well, your link is stating that the current top 3 distributions are :
1 Mint
2 Debian
3 Ubuntu
so Debian-like distributions seem a reasonable indicator ?
In case ISC’s was a clone, I assumed that rather than doing a PR to the original repo and waiting for the anser we wanted to PR to ISC/KitwareMedical’s repos (except for @phcerdan 's ITKIsotropicWavelets).
The remote module’s list here is not exhaustive, so some are still missing the update.
Let’s wait with merging until ITK master gets the minimum version bumped (planned for Friday).
We will probably have to do another round of CMake minimum version bumping, as we expect for Ubuntu 18.04 to be released with CMake 3.11 (or 3.10.1 or something).
Seems reasonable. Given that ITKv5 RC1 is planned for April 27th, and Ubuntu LTS 18.04's final release for April, 26th, I guess we’ll need to bump the new version for RC1, so bordering the feature freeze.
Another bunch of remotes PR’ed for CMake minimum version update:
BTW, I have not checked whether other changes may be necessary (or recommended, e.g. using cookiecutter/remote module template) in the code itself of the remotes to be adapted to ITKv5 :-S