Support launching cmake.exe from a VS dev environment even when not using CL

[tristanlabelle]

Brief Issue Summary

Switching the CMake compiler from cl to clang will make the CMake Tools extension stop launching cmake.exe from within a VS dev environment. This is problematic when relying on ninja from the VS installation or if using midlrt.exe from the Windows SDK, which fails if it cannot find cl.exe as a C preprocessor.

CMake Tools Diagnostics

{
  "os": "win32",
  "vscodeVersion": "1.85.1",
  "cmtVersion": "1.16.32",
  "configurations": [
    {
      "folder": "<redacted>",
      "cmakeVersion": "3.28.20231108",
      "configured": true,
      "generator": "Ninja",
      "usesPresets": true,
      "compilers": {
        "C": "cl",
        "CXX": "cl"
      }
    }
  ],
  "cpptoolsIntegration": {
    "isReady": true,
    "hasCodeModel": true,
    "activeBuildType": "RelWithDebInfo",
    "buildTypesSeen": [
      "RelWithDebInfo"
    ],
    "requests": [],
    "responses": [],
    "partialMatches": [],
    "targetCount": 184,
    "executablesCount": 0,
    "librariesCount": 184,
    "targets": []
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "always",
      "configureOnOpen": true
    }
  ]
}

Debug Log

No response

Additional Information

One solution could be to add a "cmake.alwaysUseVSEnvironment" setting.

This is related to #1836 as per discussion #3486.

[gcampbell-msft]

Thanks @tristanlabelle! I'll mark this appropriately and put this on our backlog to prioritize for upcoming releases.

[gcampbell-msft]

We are not going to be able to solve this in 1.17, so I am moving this to 1.18.

However, we have a proposal, please @tristanlabelle let us know what you think.

We would propose that we, rather than doing the "magic" that we currently do, will expose a setting that, by default, disables the use of a VS dev environment. However, this would then allow users to enable this setting, which would introduce a dev environment so that your scenario is supported.

What do you think?

[tristanlabelle]

@gcampbell-msft Yes, that's what we need. We'd also like to control the target architecture and windows sdk version to be used when setting up the vs dev environment on a per-configuration level, either because CMake Tools would deduce it from standard CMake cache variables from that configuration, or by having a specific override property in CMakePresets.json.

[gcampbell-msft]

Moved this to "On Deck" as we aren't likely to make it into the official 1.18 release. We do hope to merge this into pre-release (after releasing 1.18) as soon as we can. Thank you.

[qarni]

Maybe related to #3260 and #1897

[qarni]

Hi @tristanlabelle! Could you please test this version of cmaketools: cmake-tools-1.13.0.zip and let us know if it fixes your issue? Please make sure to change the extension from zip to vsix and install it from the Extensions menu.

[tristanlabelle]

@qarni it worked for CMake configure but the build (as invoked through a task with type: "cmake" and command: "build") fails to find link.exe and other tools that should be in the vsdevenv path.

[gcampbell-msft]

@tristanlabelle I'm investigating getting a fix for you, and I'm wondering if you can provide a small repro for the case you want to support and the issue you're seeing? As an initial fix we're trying to simply improve our "magic" such that it applies to the case where the ninja generator is missing, even if you have cl on path. Thanks

[gcampbell-msft]

@tristanlabelle Additionally, to understand your scenario better, are you only using the Ninja generator? Are there scenarios in which you are using Visual Studio generators?

Also, switching from cl.exe to clang.exe shouldn't stop CMake Tools from using the devenv, unless clang.exe already can be found on your path, so I'd like to understand more about your scenario there. Thanks!

[gcampbell-msft]

@tristanlabelle Pending your answers to the above questions, I'm expecting there to be more code changes and investigation, but I have a vsix here that I'm curious as to whether it address your fix: cmake-tools.zip

[gcampbell-msft]

@tristanlabelle I investigated further and tested out implementing a setting like the one you originally suggested, could you test it out?

cmake-tools.zip

[tristanlabelle]

Thanks for https://github.com/microsoft/vscode-cmake-tools/pull/3892 ! When should we expect to see this in a release? (and meanwhile, in a pre-release?) @gcampbell-msft

[gcampbell-msft]

@tristanlabelle You should see the changes in pre-release now. As for an official release, we try our best to follow the schedule we set here: https://github.com/microsoft/vscode-cmake-tools/wiki/Release-schedule

[OkazakiNagisa]

Maybe this feature should be more versatile? like environmentSetupScript but for preset.

[tristanlabelle]

@OkazakiNagisa , if this were implemented as a script to be invoked, we'd have to hardcode the path to the vsdevcmd batch file, and it couldn't rely on detecting the architectures and toolsets from the presets. I think it needs special support.

[OkazakiNagisa]

MSVC indeed requires special handling by vswhere👀

I mean cmake-tools can support environment setup mechanism for preset by calling vswhere, or a script (cmake toolchain is unnecessary since it can be assigned in cmake preset file), like cmake-kits schema.

This would be useful when using EWDK toolchain, which is not detectable by vswhere but by design