New machine experience: Ninja not found (in VS, even though it can find CMake in the VS installation just fine)

[TheJCAB]

Brief Issue Summary

This is a basic ease-of-use user experience issue.

A fresh machine, with VS 2022 installed on it and ready to go. Open a CMake/Ninja project folder VSCode, and try to build. This happens:

...
[cmake] CMake Error: CMake was unable to find a build program corresponding to "Ninja".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
[proc] The command: "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" *redacted* -G Ninja exited with code: 1

So... it can find "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" just fine (it's not in the PATH). But it can't be bothered to put, say, "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja" in the PATH when calling CMake.

This sounds like a relatively simple fix. Ninja is included in VS along with CMake, and it should be usable right out of the box, no?

Thanx!

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

No response

[benmcmorran]

Thanks for the report! The suggestion sounds reasonable to me. As a workaround, are you able to launch VS Code from a Visual Studio Developer Command Prompt? That should have all the proper environment variables set for Ninja (and MSVC) to be easily discoverable.

@sinemakinci1 FYI this is related to our broader discussion about streamlining tool acquisition.

[Thomas1664]

I'm experiencing the same issue. As a result, I'm unable to build anything using Ninja. The suggested workaround is not viable because opening VS Dev CMD is too complicated for the simple task of just opening a folder. It should "just work".

[gcampbell-msft]

@Thomas1664 Could you provide exact repro steps for when you're seeing this? Are you using kits / presets? What type of project are you opening? Etc.

[Yingzi1234]

@gcampbell-msft We can reproduce this issue on latest VSCode and you can get the details below.

ENV:

1. VS: 17.11 Preview1.0
2. VSCode: 1.88.1
3. C/C++: v1.20.2
4. CMake tools: v0.0.17
5. Gcc: 13.2.20
6. Clang: 18.1.4

Repro steps:

1. Create any cmake project with c language.

2. Create main.c file: _#include <stdio.h> #ifdef _WIN32 #include <windows.h> #endif int main() { #ifdef WIN32 SetConsoleOutputCP(65001); #endif return 0; }

3. Create CMakeLists.txt: cmake_minimum_required(VERSION 3.20.0) project(t VERSION 0.1.0) aux_source_directory(. SRC) add_executable(t ${SRC}) set(CPACK_PROJECT_NAME ${PROJECT_NAME}) set(CPACK_PROJECT_VERSION ${PROJECT_VERSION})

4. Create CMakePresets.json file: { "version": 3, "configurePresets": [ { "name": "gcc-base", "hidden": true, "generator": "Ninja", "binaryDir": "${sourceDir}/out/build/${presetName}", "installDir": "${sourceDir}/out/install/${presetName}", "environment": { "PATH": "C:/msys64/mingw64/bin/;$penv{path}" }, "cacheVariables": { "CMAKE_C_COMPILER": "gcc.exe", "CMAKE_CXX_COMPILER": "g++.exe" }, "condition": { "type": "equals", "lhs": "${hostSystemName}", "rhs": "Windows" }, "vendor": { "microsoft.com/VisualStudioSettings/CMake/1.0": { "intelliSenseMode": "linux-gcc-x64" } } }, { "name": "clang-base", "hidden": true, "generator": "Ninja", "binaryDir": "${sourceDir}/out/build/${presetName}", "installDir": "${sourceDir}/out/install/${presetName}", "environment": { "PATH": "C:/msys64/mingw64/bin/;$penv{path}" }, "cacheVariables": { "CMAKE_C_COMPILER": "clang.exe", "CMAKE_CXX_COMPILER": "clang++.exe" }, "condition": { "type": "equals", "lhs": "${hostSystemName}", "rhs": "Windows" }, "vendor": { "microsoft.com/VisualStudioSettings/CMake/1.0": { "intelliSenseMode": "windows-clang-x64", "intelliSenseOptions": { "useCompilerDefaults": true } } } }, { "name": "gcc-debug", "displayName": "gcc Debug", "inherits": "gcc-base", "architecture": { "value": "x64", "strategy": "external" }, "cacheVariables": { "CMAKE_BUILD_TYPE": "Debug" } }, { "name": "clang-debug", "displayName": "clang Debug", "inherits": "clang-base", "architecture": { "value": "x64", "strategy": "external" }, "cacheVariables": { "CMAKE_BUILD_TYPE": "Debug" } } ] }

5. Click F1 to configure the project and select preset ”clang debug”, then build it

Expected result: The project can be successfully built

Actual result: The build will fail and the error message on the left will appear in the output window. Output log： [main] Building folder: Test1 clean [main] Configuring project: Test1 [proc] Executing command: "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.EXE" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang.exe -DCMAKE_CXX_COMPILER=clang++.exe -DCMAKE_INSTALL_PREFIX=C:/Users/v-cathyzhang/Desktop/Test1/out/install/clang-debug -SC:/Users/v-cathyzhang/Desktop/Test1 -BC:/Users/v-cathyzhang/Desktop/Test1/out/build/clang-debug -G Ninja [cmake] CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. [cmake] -- Configuring incomplete, errors occurred! [proc] The command: "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.EXE" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang.exe -DCMAKE_CXX_COMPILER=clang++.exe -DCMAKE_INSTALL_PREFIX=C:/Users/v-cathyzhang/Desktop/Test1/out/install/clang-debug -SC:/Users/v-cathyzhang/Desktop/Test1 -BC:/Users/v-cathyzhang/Desktop/Test1/out/build/clang-debug -G Ninja exited with code: 1

[gcampbell-msft]

@TheJCAB @Yingzi1234 This is a known limitation that we are currently investigating / working on improving. Possibly by implementing something like #3497.

[TheJCAB]

@gcampbell-msft Yes, thanx! That sounds like a similar issue, and I agree that improving/generalizing tool acquisition (as mentioned here before) would provide good benefits.

The extension generally doesn't rely on VSCode being launched from a developer command prompt, which would preclude fully using it as a GUI (launch from Start menu, taskbar or desktop shortcut, open directory/project from the recent list, etc...). That's a good thing, except when it doesn't work, as reported here and in that other issue.

Another similar issue we experience is in vcpkg, where it attempts to locate tools like dumpbin and fails. It uses this to read the dependencies of built binaries, and copy any dependencies built by vcpkg. This is noisy but benign (we only use header libraries, so all this work vcpkg does is not really needed in our case).

[Yingzi1234]

We're glad your issue is being addressed! For the other issue, could you reopen a new issue for it and add the details to it? That would help us track down the issue a lot more. Thank you!

[gcampbell-msft]

Related to #3497

[qarni]

Hi, @TheJCAB, 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.

[TheJCAB]

@qarni I'll need to set up a new machine/VM for this. In the meantime, your .zip says 1.13 but the extension is up to 1.18 now. Why the discrepancy? I'd expect a test install to be relatively current...

[gcampbell-msft]

@TheJCAB It is current, we often leave it at an old version so that test installations don't overtake your current version except for testing.

[Yingzi1234]

@qarni @gcampbell-msft @TheJCAB This issue has been fixed on this versioncmake-tools-1.13.0.zip, you can get the details below. Please let me know if you have any concerns! Thank you for your help!

[TheJCAB]

@qarni I couldn't reproduce the issue with the 1.13 test build. But I was also unable to reproduce the issue with the current 1.18 either. I didn't set up a fresh VM for this, though (I just removed/renamed all ninja tools outside of VS), so I might have missed something. Maybe the path got centrally cached somewhere?

I ran the test by building with both: cl.exe and clang-cl.exe, and I verified that I have no ninja.exe in the path when I launch VSCode, but still it somehow managed to find the one in VS.

So, inconclusive for me, but the change looks good, thanx!

[gcampbell-msft]

@Thomas1664 Are you still able to reproduce your issue?

[gcampbell-msft]

I have another vsix here to test, where we also check for if ninja is missing when you're trying to use ninja, and if so, add it if we can find it from vs devenv.

cmake-tools.zip

[Thomas1664]

@Thomas1664 Are you still able to reproduce your issue?

@gcampbell-msft I can still reproduce this issue in v1.19.27. I can't find the setting cmake.useVsDeveloperEnvironment. Am I using the latest version of the extension or do I need a newer VS Code (currently 1.19.1)?

[gcampbell-msft]

You shouldn't need a newer VS Code, could you try reloading the window? I am on 1.19.27 and I see the setting available:

[Thomas1664]

You shouldn't need a newer VS Code, could you try reloading the window?

@gcampbell-msft Yesterday it worked after setting cmake.useVsDeveloperEnvironment to always. I just updated the extension and it stopped working. Reloading the window also didn't help. The VS dev environment is used when starting the extension and it finds Ninja. But when I try to run configure, it uses the CMake command directly, not inside VS dev environment. I then switched back to normal releases and version 1.18.43 works.

[gcampbell-msft]

@Thomas1664 This may be a regression related to #3905, could you please create an issue with explicit reproduction steps? We would want to fix this before releasing any official release.

[gcampbell-msft]

@Thomas1664 I followed up on the new issue you created, if you could please try out the new vsix or test out the PR I created, that would be great.