Raise CMake requirement

[friendlyanon]

Right now, people consuming projects generated with cmake-init are required to have at least CMake 3.14 installed and developers developing those projects are recommended to have at least 3.20 installed to make use of presets.

Group	Minimum CMake version	Reason
Consumers	3.14	install(TARGETS) uses the correct cross-platform paths when omitted FetchContent is more convenient to use Improvements from earlier versions
Consumers	3.xx	C++23 template with import std; available See #55 for tracking modules Improvements from earlier versions
Developers	3.20	Presets version 2 (enables users with VSCode's "CMake Tools" extension) Build and tests presets simplify command line workflow ctest --test-dir to run tests from anywhere Improvements from earlier versions
Consumers	3.32 (?)	CPS support Improvements from earlier versions

[friendlyanon]

CMake 3.20 introduced presets version 2, which is what could fix #34. This version also added the --test-dir argument to ctest which enables the developer to run tests from any working directory.

[ClausKlein]

IMHO: this should not a problem to do so.
CMake may be easily installed or updated from pypi

[ClausKlein]

In general, I would prefer the ranged version of

cmake_minimum_required(VERSION <min>[...<policy_max>])

See too https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html#policies-introduced-by-cmake-3-20

[friendlyanon]

The requirement is not raised willy-nilly just for the sake of raising it. Especially the range form of the command, for which I have not found a single use-case yet. Everytime the more sensible thing would have been just raising the minimum requirement to begin with. The minimum required version must have a good reason to be selected, see the table above.
The next time it will have to be increased is when C++23 comes into play and the standard library will provide a module interface (import std;), but that will be localized to C++23 and newer standards only. Compilers are slow with implementing modules anyway, and CMake already supports modules since 3.20.

There are also the file sets introduced in 3.23 (https://cmake.org/cmake/help/latest/release/3.23.html#commands), but I'm not sure about their value as of yet. I will likely create an example project utilizing it and add it to the growing list of examples as a way to evaluate the feature.

[friendlyanon]

In C++20, the standard library's headers are usable as header units in modules, however C++23 provides a much better interface via import std;, so coupled with no compiler properly supporting modules yet, it's best to delay modules in this project until C++23. #55 is tracking modules.

[ClausKlein]

What are the reasons you want to stay back with improvements independently form C++23?

Newer CMake versions can be easily installed with pip install cmake on each platform.

[anders-wind]

There are also the file sets introduced in 3.23 (https://cmake.org/cmake/help/latest/release/3.23.html#commands), but I'm not sure about their value as of yet. I will likely create an example project utilizing it and add it to the growing list of examples as a way to evaluate the feature.

One of the cmake authors, here writes that they discourage the use of target_include_directories and prefer that users start using file sets: https://www.reddit.com/r/cpp/comments/1f6gh89/comment/ll0a18z/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[ClausKlein]

One of the cmake authors, here writes that they discourage the use of target_include_directories and prefer that users start using file sets

Yes, but not on www.reddit.com!

see https://gitlab.kitware.com/cmake/cmake/-/issues/26105

[ClausKlein]

See CMake News https://www.kitware.com/import-std-in-cmake-3-30/