friendlyanon / cmake-init

The missing CMake project initializer
GNU General Public License v3.0
1.98k stars 75 forks source link

Raise CMake requirement #28

Open friendlyanon opened 2 years ago

friendlyanon commented 2 years ago

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.

GroupMinimum CMake versionReason
Consumers 3.14
Consumers 3.xx
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
friendlyanon commented 2 years ago

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 commented 2 years ago

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

ClausKlein commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 5 months ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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