Bump cmake_minimum_required to 3.21

[ihnorton]

TYPE: IMPROVEMENT
DESC: Bump cmake_minimum_required to 3.13

[Shelnutt2]

@ihnorton centos/rhel 7 has cmake 3.12. Do we need 3.13 or would 3.12 be acceptable too?

[eddelbuettel]

This is fine. I tried to find a concise on-line representation of 'where cmake commonly is' and that is difficult so I didn't post anything. The closest may be the various tabs in the repology site entry and while no single one is fully answering it (given the widespread use of cmake and repology's insistence on covering largely irrelevant entries (AIX, anyone?)) the badges one may come closest.

So 3.13 should be fine.

[dhoke4tdb]

Related to Seth's question, visual studio 2017 is version cmake version 3.12.18081601-MSVC_2, also a 3.12 derivative.
Are we leaving vs2017 behind now? (or forcing use of later cmake obtained external to VS installation?)

[eric-hughes-tiledb]

forcing use of later cmake obtained external to [VS 2017, ... or whatever else]

It's not part of this PR to decide this, but I'd like to have some estimate about what kind of actual cost this would be of requiring even-more recent versions of CMake. A clearly-labeled requirement that the user "must use an updated version of CMake", combined with an explicit bail-out in our CMakeLists.txt (not just relying on the version command), might be acceptable as long as we're not too aggressive about pushing the required version up.

I'm constantly fighting with our build, and a good part of that is that we're unable to use more recent CMake features and so we've got a build that's stuck in the past in a bad way. For example, 3.20 has a full preset facility (begun in 3.19), which allows specification of a large number of configuration parameters that are otherwise passed in disparate ways. Being able to lock all these down would isolate our build from variation from environmental defaults and other sources. There's a feature in 3.18 that would directly address a problem I'm having this week with the superbuild:

The find_program(), find_library(), find_path() and find_file() commands gained a new REQUIRED option that will stop processing with an error message if nothing is found.
Also a small-looking but significant change would allow a lot of cleanup in the build:
Since CMake 3.19, an INTERFACE library target may optionally contain source files

There's a lot of this kind of thing happening lately. I'm all in favor of being as aggressive as possible about CMake versions. Unlike compilers, there's no ABI back-compatibility issues.

[eric-hughes-tiledb]

Wholeheartedly approve.

[eddelbuettel]

I had overlooked the CentOS 7 concern, my bad, Those systems are (sadly) quite common. Now, in order to build there (given our use of C++17) we likely require the devtoolset anyway. Can a newer cmake be made available for those users? Could we (worst case) even provide an rpm ourselves?

[ihnorton]

PR to bump rtools40 cmake version: r-windows/rtools-packages#229

[ihnorton]

Ok, this is g2g and passing with cmake 3.21, should we choose to make the jump to lightspeed.

[Shelnutt2]

@ihnorton the manylinux image test is failing because it is on cmake 3.20. Can we upgrade to the latest manylinux, say 2021-11-07-28723f3 which has cmake 3.21.4?

[ihnorton]

Sure, don't see why not.