cmake: increase required version to 3.22

[nilason]

Increase required CMake version to 3.22 (Nov 2021), replacing current version 3.16 (Nov 2019).

That version would be supported out-of-the-box with, e.g.:

• Debian 12 Bookworm (current stable)
• Fedora 36 (EOL)
• Slackware 15.0 (current stable)
• Ubuntu 22.04 (Jammy Jellyfish, EOL in Apr 2027)

See further platforms: https://repology.org/project/cmake/versions

Otherwise it may be installed through pip.

Version 3.22 comes with a number of useful improvements, among others for Apple ARM platform support, FindGDAL and FindPostgreSQL. See links below for news posts for each upgrade:

https://cmake.org/cmake/help/latest/release/3.17.html
https://cmake.org/cmake/help/latest/release/3.18.html
https://cmake.org/cmake/help/latest/release/3.19.html
https://cmake.org/cmake/help/latest/release/3.20.html
https://cmake.org/cmake/help/latest/release/3.21.html
https://cmake.org/cmake/help/latest/release/3.22.html

[wenzeslaus]

... FindGDAL and FindPostgreSQL.

Can you delete some of the CMake code, then?

[nilason]

... FindGDAL and FindPostgreSQL.

Can you delete some of the CMake code, then?

I have one PR prepared for PostgreSQL (similar to #5263), where we can drop the custom FindPostgreSQL file with 3.20. To mention a concrete example, in fact the reason I started to look at this.

[nilason]

Point of reference: QGIS just bumped to 3.23.

[echoix]

Point of reference: QGIS just bumped to 3.23.

Makes sense if they started to use FILE_SETs.

[nilason]

Point of reference: QGIS just bumped to 3.23.

Makes sense if they started to use FILE_SETs.

With the cost of being broken on Jammy.

[echoix]

CMake is great for backwards compatibility (that isn't the same as forward compatibility). It is self contained, a generator for build tools that can be downloaded as will (it is not a build tool itself), and the one used needs to be at least newer as your compiler. It can workaround warts of older compilers. It is not a dependency that will be baked into the built result.

I remember the discussion when we tried to settle on a version 2 or three years ago. I'm more to go with a reasonably high version, especially since we are an application rather than only a library. We are in the advantageous situation where no preexisting user workflows depend on a certain setup, so we dont have to worry about compatibility yet.

What is great is to set the version max to the latest one tested that works (and bump it up often). It will set the policies to "NEW" up until that version where it is known to work. Usually, the min version should be actually tested. But using greater versions is still better.

[nilason]

We are in the advantageous situation where no preexisting user workflows depend on a certain setup, so we dont have to worry about compatibility yet.

I might add that the existing build system is there for still some time. When we're ready for FHS, CMake will be the only way forward.

[echoix]

We are in the advantageous situation where no preexisting user workflows depend on a certain setup, so we dont have to worry about compatibility yet.

I might add that the existing build system is there for still some time. When we're ready for FHS, CMake will be the only way forward.

That's why we can say: if you want to build grass with CMake, you need that arbitrary CMake version