CMake Presets

[JonasGilg]

This PR adds CMake Presets. An official CMake feature to share common configurations of a project.

On Windows there are presets for Ninja (with Visual Studio as a toolchain) and Visual Studio. On Linux there are Ninja and Make presets.

I decided to use the presets version 3 which was introduced with CMake 3.22, since this is the CMake version coming with Ubuntu 22.04. It is notable, that later versions of presets (current one is 9) come with more features that are also very useful, like workflows.

Usage with the command line

List configuration presets:

> cmake --list-presets
Available configure presets:

  "windows-ninja-release-config"
  "windows-ninja-debug-config"
  "windows-vs-release-config"
  "windows-vs-debug-config"

Configure with a preset:

> cmake --preset windows-ninja-release-config
Preset CMake variables:

  CMAKE_BUILD_TYPE="Release"
  CMAKE_EXPORT_COMPILE_COMMANDS="On"
  CMAKE_INSTALL_MESSAGE="LAZY"
  CMAKE_INSTALL_PREFIX="C:/LocalData/C++/cs-review/install/windows-Release"
  CMAKE_TOOLCHAIN_FILE:FILEPATH="C:/LocalData/C++/cs-review/cmake/Windows.MSVC.toolchain.cmake"
  CMAKE_UNITY_BUILD="On"
  COSMOSCOUT_EXTERNALS_DIR="C:/LocalData/C++/cs-review/install/windows-externals-Release"
  COSMOSCOUT_UNIT_TESTS="On"
  COSMOSCOUT_USE_PRECOMPILED_HEADERS="On"

[...]

List build presets:

> cmake --build --list-presets
Available build presets:

  "windows-ninja-release-build"
  "windows-ninja-debug-build"
  "windows-vs-release-build"
  "windows-vs-debug-build"

Build with a preset:

> cmake --build --preset windows-ninja-release-build
[...]

Usage with IDEs

CLion and VSCode can understand preset files and give the option to use the settings for setting up the IDE. I updated the CLion docs to use the presets and make it easier to setup.

Since I don't use VSCode I left is as is for now, maybe somebody else wants to update that section.

I also removed the docs for Sublime and Eclipse, since they aren't widely in use and we don't have anybody actively check if the documentation is still up-to-date.

Additional Notes

I added Toolchain files for Visual Studio, which allow Ninja presets to use the newest installed Visual Studio instance, even if it is not on the path. Previously Ninja defaulted to MinGW or Clang, since they put themselves on the Path on installation, while the VS toolchain only worked, when using the Visual Studio Developer Console.

I also decided to not specify any generator in the Visual Studio preset, which results in CMake choosing a generator for you. On Windows CMake will automatically choose the newest installed Visual Studio version. This might break in the future, if CMake decides to change the generator precedence, but this is the only way to offer a single preset for Visual Studio. Otherwise we would need presets for each supported Visual Studio version.

[github-actions]

Pull Request Test Coverage Report for Build 10008246474

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 1.179%

---

Totals
Change from base Build 9972927207:	0.0%
Covered Lines:	193
Relevant Lines:	16366

---

💛 - Coveralls

[Schneegans]

Thanks a lot! I am currently playing around with this and it seems to work pretty well. Do you think that we should maybe even remove the make.bat and make.sh scripts in favor of the presets?

[JonasGilg]

Thanks a lot! I am currently playing around with this and it seems to work pretty well. Do you think that we should maybe even remove the make.bat and make.sh scripts in favor of the presets?

We could remove them, but I am not 100% sure if we should. The user has to enter more commands with CMake presets (configure and build). With CMake 3.25 workflows will be added, which should reduce this to a single command. Maybe we can rewrite the make scripts to use presets and give the preset name as an argument and it automatically does the configure and build step (as a temporary replacement of workflows)?

On the other side: I probably makes sense for the user to just use standard CMake features and it would overcomplicate our project to offer multiple ways to build it.

In conclusion I think we can replace it. I will rewrite the docs section for that.

[Schneegans]

Will you do this in this PR?

[JonasGilg]

Will you do this in this PR?

Yes, I haven't come around doing it yet. Probably tomorrow afternoon.