cmake 3.31 now errors when 3.19 or earlier is requested

[theodoregoetz]

When configuring VSG (and associated projects like vsgXchange) with cmake version 3.31, The following deprecation error is emitted:

> cmake --version
cmake version 3.31.1
> cmake -B build -S .
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.


-- The CXX compiler identification is GNU 14.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
...

Changing the first line of the CMakeLists.txt to cmake_minimum_required(VERSION 3.10) clears the warning, but there may be a way to still support 3.7 by using the <min>...<max> specification as suggested - though I did not test that since 3.10 was released on Nov 30, 2018 which is already quite a while ago.

[robertosfield]

What platform has 3.31?

We'll need to look to see what platforms support 3.10 and later. I chose 3.7 back in the early days of the VSG, so probably Kubuntu 16.04 was likely my starting place.

[AnyOldName3]

That's a warning, not an error, so it can be ignored for a while. CMake's been complaining that backwards-compatibility for 3.5 will be removed since 3.27, and they took until 3.31 before they expanded that to cover 3.10 and older. Based on https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9875#note_1577553, they don't have a plan on when support will be dropped for real, so there's no huge rush.

As for which platforms have which versions, it's pretty typical for Windows and MacOS users to already be on a close-to-latest version, and have no qualms about updating, so it's only Linux that needs particular attention to the minimum version. It does mean that Windows and MacOS users will have problems if CMake does ever get around to dropping support, though, but so will Arch users, as they're usually not far behind. I typically find Debian's oldest non-EoL LTS version is a good indication of what's a safe minimum, and that's currently Bullseye, which is on 3.18.4. 3.18 is from mid-2020, which is bizarrely new for Debian, so I'm wondering if they've changed their policy since I last did this. Ubuntu 16.04's still under paid support and only has 3.5, but I can't find details on the cmake package for Debian Jessie (their oldest version under paid support) as their public package listing doesn't cover releases that old. As another datapoint, Ubuntu 20.04's still under free support, and has 3.16.3.

I guess that instead of looking at a few specific distros, it might be simpler to look at https://pkgs.org/download/cmake and https://pkgs.org/download/cmake3 (some distros still ship CMake 2 as cmake and CMake 3+ are cmake3). Annoyingly, it doesn't look like this tool has population percentages like an OpenGL/Vulkan extension database, so it's unclear which distros are rare enough that they're not worth worrying about.

Something that's worth bearing in mind, and that I've said before but will repeat as it's often forgotten, is that cmake_minimum_required isn't a version check. It does do a version check and error out with too-old CMake, but it also puts CMake into backwards compatibility mode for the specified version. Before the number can be safely increased, it's necessary to look through https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html and see which new policies were introduced, and work out which might affect the project. If any would be a breaking change, it's necessary to adapt to the new policy, or at least explicitly opt into the old behaviour. The latter approach is less ideal as they're likely to drop support for policies at the same time as dropping support for old versions that used the old behaviour of the policies.