microsoft
Moving forward: Upcoming priorities for CMake Presets support
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
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/[email protected]/
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 :)
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.
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?
@equeim @melak47 Thank you so much for your feedback, I have opened this issue for us to track your requests: https://github.com/microsoft/vscode-cmake-tools/issues/4225.
@melak47 Does setting the "cmake.useVsDeveloperEnvironment" setting to "always" mitigate the issue you're hitting?
Does setting the "cmake.useVsDeveloperEnvironment" setting to "always" mitigate the issue you're hitting?
@gcampbell-msft it does, thanks! Though reading the description of that setting:
Selecting auto will only apply the Visual Studio environment when we detect a supported compiler (cl, clang, clang-cl, clang-cpp, clang++), or the Ninja generator is being used.
It seems like it doesn't work exactly as described, as I am using the Ninja generator (both in the preset as well as in the cmake.generator setting).
I'm just bringing up cmake for us now, using presets from the start. I'm new to this! One thing that is odd for me is that when I invoke a test through the Testing panel, it always starts by invoking cmake to build the entire preset. This should be / is quick, however in the case of someone making a broad change I can see they may want to run some tests before necessarily everything compiles successfully.
We're using the Ninja generator. Wouldn't it make more sense that when you press Run Test, Debug Test, or Run Test with Coverage, it invokes Ninja to build the particular binaries necessary? And if this isn't something that is universally true, is there any way we can override the behavior for ourselves?
Tóm tắt vấn đề ngắn gọn
Những người duy trì tiện ích mở rộng CMake Tools có kế hoạch ưu tiên nỗ lực hỗ trợ cho các trải nghiệm dựa trên cài đặt trước của CMake thay vì các trải nghiệm dựa trên bộ công cụ CMake.
Chúng tôi khuyến nghị bạn nên sử dụng cài đặt sẵn CMake cho các dự án CMake của mình, vì đây là tích hợp được khuyến nghị từ chính Kitware, cho phép xây dựng đa nền tảng và dễ dàng tái tạo, đồng thời tích hợp tốt nhất vào tiện ích mở rộng của chúng tôi. Do đó, chúng tôi dự định ưu tiên các hạng mục công việc và PR tuân thủ cài đặt sẵn trong tương lai để hỗ trợ tốt nhất cho kịch bản được đề xuất.
Nếu bạn đang sử dụng CMake Kits và Variants cho bản dựng của mình, vui lòng cho chúng tôi biết nếu có bất kỳ thiếu sót nào khiến bạn chưa thể tích hợp vào các cài đặt trước để chúng tôi có thể phục vụ bạn tốt nhất. Bạn có muốn tài liệu hướng dẫn chi tiết hơn không? Có điều gì bạn thích về trải nghiệm CMake Kits nói chung khiến bạn thích nó hơn không?
Hãy thoải mái để lại bất kỳ bình luận hoặc thắc mắc nào về vấn đề này để chúng ta có thể thảo luận!
Chẩn đoán Công cụ CMake
Không
cóphản hồiNhật ký gỡ lỗi
Không có phản hồi
Thông tin bổ sung
Không có phản hồi
