[Meta] Controlling the environment with presets

Brief Issue Summary

This issue is borderline a discsussion and intends to collect feedback around finding a solution for a number of issues around the inability to properly control or infer the environment to drive toolchains. An honest effort to enumerate related issues:

• #2912
• #3436
• #2036
• #1897
• #1885
• #2286

Relevant upstream issues:

• presets: sourcing environment scripts #21619

This linked issues, especially the upstream one has a fair amount of context. The takeaway in my read about all of it is:

• CMake (and Kitware) does not wish to concern itself with setting up an environment for configuring using makefile generators
• Users clearly want CMake to be concerned with that
  • It is a constant source of friction
  • IDE tooling can only mitigate the issue, but cannot solve it. CMake Tools can't help us in CI scenarios
• Presets already has a built-in mechanism to control the environment
  • The configuration env can propagate to build and tests in a well defined manner

The solution space is vast.

• Do what CMake Tools tries to do now and trigger extra logic for "strategy": "external" mixed with inspecting CMAKE_[C|CXX]_COMPILER
  • this won't help with shell/script/CI use-cases.
  • even in the IDE, this breaks with less popular toolchains.
    • nvc++, amdclang++, etc. I happen to be a GPGPU dev, so this is my everyday use-case.
    • I constantly keep getting Neither dumpbin, llvm-objdump nor objdump could be found. Can not take care of dll dependencies. warnings on every target when using Vcpkg because CMake Tools cares not about the env in my preset.
• One of the issue authors advocates for supporting the "cmakeGenerateCommand" preset vendor extension
  • neither will this help with shell/script/CI use-cases.
• Have CMake persist env changes during configuration-time to build/test/package-time and enact env reqs in CMAKE_TOOLCHAIN_FILEs or CMAKE_PROJECT_TOP_LEVEL_INCLUDES.
  • This requires CMake changes
• Have tools respect environments setup through presets and have toolchains declare their env requirements in a preset-friendly way.
  • This is what I've been trying to advocate for in the upstream issue here.
• ??? (something else?)

To elaborate a bit further on each, IDEs and other tools (GitHub/GitLab CI, homebrew scripts) trying to take on the burden of bootstrapping the environment is duplication of effort, yet another source of friction (CI matrix entries have to match exactly what GitHub actions / vcavrsall / etc. accept as arguments).

Telling users to launch their IDE from an appropriate shell is no solution either, switching betweenNVCC, NVC++, ROCmCC becomes tedious very soon, or we'll need to have 3 shells and 3 IDEs opening the same folder, which will drive other tooling crazy.

Proposed solution

If CMake can find all the MSBuild installations on a given system, why can't CMake (or even just toolchain vendors collectively) canonicalize some location on disk where toolchains/users can install their preset fragments which can then be included? This would likely need preset JSON schema extensions and behavioral additions. Proper MSBuild installations are detectable by CMake, at which point the user selects a toolchain using a custom string such as "v143,host=x64". Users of makefile driven toolchains (once CMake included all the JSONs from a canonical location) could also select one using either some string or something more structured. It could be something as simple as "llvm-latest", "llvm-16", or "visual-studio-17-2022-msvc-v143", "amd-rocm-latest" with each vendor coming up with a convenient string format, but could also be something more structured extending the available "condition"s with things like "versionGreaterEqual", etc.

I don't want to go too muc into detail, as it's not that important. What is currently missing is consensus on wanting to address the issue and doing so in a coordinated fashion (from Kitware's and tool vendor's POV).

My current workaround is running a custom script on every toolchain update that saves it in a non-standard location and exposes the environment as a hidden preset which other presets inherit, for eg. "developer-command-prompt-clang-rocm". This works fine locally, while CMake Tools outright disregards this, but in CI if I need to run a custom script, I'm back to square 1, at which point I may as well have used some action like Enable Developer Command Prompt.

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

No response

The issue names no repository files, tests, or entry points. Begin by reading the linked upstream CMake issue and the related issues listed here; a concrete contribution would require an agreed scope, affected preset behavior, and an explicit acceptance criterion before implementation can start.