Moving forward: Upcoming priorities for CMake Presets support

[sinemakinci1]

Brief Issue Summary

The CMake Tools extension maintainers plan to prioritize efforts towards support for CMake presets-based experiences opposed to CMake kits-based experiences.

Our recommendation is to use CMake presets for your CMake projects, as this is the recommended integration from Kitware themselves, allows for cross-platform and easily reproducible builds, and has first-class integration into our extension. Due to this, we plan to prioritize work items and PRs that are compliant with presets moving forward to best support our recommended scenario.

If you are using CMake Kits and Variants for your builds, please let us know if there is any gap that is preventing you from onboarding to presets so that we can best serve you. Would you like better documentation? Are there things you like about the Kits experience in general that leads you to prefer it?

Feel free to leave any comments or concerns on this issue so we can discuss!

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

No response

[zoink47]

Hi,

we are heavily relying on the environmentSetupScript key in cmake-kits.json. It doesn't seem to exist in CMake Presets.

According to this issue over at the CMake project it seems to be intentionally left out: https://gitlab.kitware.com/cmake/cmake/-/issues/21619

The environmentSetupScript makes it really easy to use Yocto SDKs, since this the default way to use it with cmake tool chain files (sourcing the environment setup script for e.g. $CC and then using the cmake tool chain file): https://docs.yoctoproject.org/dev/sdk-manual/using.html#running-the-sdk-environment-setup-script

Unfortunately Yocto is lacking documentation on using the SDK with cmake, here is what I found:
https://patchwork.yoctoproject.org/project/oe-core/patch/20220331024645.655-1-workjagadeesh@gmail.com/

https://docs.yoctoproject.org/sdk-manual/working-projects.html

Sourcing the environment script from command line and then opening code from the terminal is also only partially solving the issue. We use the remote ssh/WSL extension a lot, and sourcing an environment before opening the remote/WSL session doesn't seem to be possible.

It would be great to somehow have the environmentSetupScript key available when used with CMake Presets, otherwise we still need to rely on CMake Kits (here is to hope that the cmake tools extension will not drop CMake Kits support).

Thanks in advance :)

[equeim]

There should be better feedback about automatic setup of MSVC dev environment with presets. It took me a long time to figure out that I needed to set CMAKE_CXX_COMPILER to cl.exe explicitly in my CMakePresets.json for it to work. Since this is not needed for typical command line / CI workflows where you set up the environment manually (and rely on CMake to correctly guess that you want to compile with MSVC), some help from IDE is desirable here.

[melak47]

There should be better feedback about automatic setup of MSVC dev environment with presets. It took me a long time to figure out that I needed to set CMAKE_CXX_COMPILER to cl.exe explicitly in my CMakePresets.json for it to work. Since this is not needed for typical command line / CI workflows where you set up the environment manually (and rely on CMake to correctly guess that you want to compile with MSVC), some help from IDE is desirable here.

I ran into similar problems (with conan-generated CMakePresets.json that do not set CMAKE_CXX_COMPILER, because it's being set in a toolchain file).

From what I can tell, Visual Studio and even JetBrains CLion do not need "CMAKE_CXX_COMPILER": "cl" as an explicit hint in the preset to provide the MSVC environment setup, just the toolset/architecture keys are enough.

Would it be possible to drop this requirement in cmake-tools, reducing friction with presets authored by/for other tools/IDEs?

[sinemakinci1]

@equeim @melak47 Thank you so much for your feedback, I have opened this issue for us to track your requests: #4225.

[gcampbell-msft]

@melak47 Does setting the "cmake.useVsDeveloperEnvironment" setting to "always" mitigate the issue you're hitting?