Closed jeremicmilan closed 5 months ago
@jeremicmilan Thank you for notifying us of this. That is definitely not desirable to see this much output, and more importantly, to see a big slowdown when switching between presets and/or saving updates to presets.
We will investigate this, and based on workload and backlog, prioritize this so we don't have bad performance.
I confirm that I have this behavior too, initialization is very slow.
But more globally, choosing an MS compiler version with CMake/Ninja and make it work on multiple IDEs is not an easy task. Ex :
code
, it works well... except if VSCode was already open on a WSL project. Then the environment variables seem to be shared between the 2 windows.Edit User-Local CMake Kits
command doesn't exist (probably because I use cmake presets?): https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/kits.md#user-local-kits {
"name": "windows",
"cacheVariables": {
"CMAKE_C_COMPILER": "cl.exe",
"CMAKE_CXX_COMPILER": "cl.exe",
"CMAKE_MAKE_PROGRAM": "ninja.exe"
},
"binaryDir": "${sourceDir}/build",
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Windows"
},
"generator": "Ninja Multi-Config",
"toolset": {
"value": "v143,version=14.2,host=x64",
"strategy": "external"
},
"architecture": {
"value": "x64",
"strategy": "external"
}
}
The documentation is very light on the subject, maybe a tutorial/use case example would help.
Also, I wonder if vcvars result could be put in a cache file, because it is slow. I did this before finding about CMakePresets toolset support:
setenv.ps1:
if (!(Test-Path $PSScriptRoot\build\vcvars.txt)) {
if (!(Test-Path $PSScriptRoot\build)) {
mkdir $PSScriptRoot\build
}
# vs2022 compiles with 2019 tools + recent CMake
cmd.exe /c "call `"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\Build\vcvars64.bat`" -vcvars_ver=14.2 && set > $PSScriptRoot\build\vcvars.txt"
}
Get-Content "$PSScriptRoot\build\vcvars.txt" | Foreach-Object {
if ($_ -match "^(.*?)=(.*)$") {
Set-Content "env:\$($matches[1])" $matches[2]
}
}
@nmoreaud Thanks for the follow up. I can confirm that we know about this issue and have a fix. We had been waiting for some other changes that we planned to initiate it, but to confirm that what I have locally fixes the issues, could you test with this vsix?
You'll need to download it, change the extension to .vsix, and then install it manually. Thanks!
@gcampbell-msft, I can confirm that the fix works for Ninja+MSVC. Thanks! It's awesome to see the switch working quickly, as well, as being cached when switching back and forth (vcvars not executed on the switch every time). When can we expect this to land into the public release of the extension?
Another problem I started hitting recently, not sure if related: Ninja+Clang is not loading the VS environment. I believe this worked a month or two ago, but it stopped working few weeks ago. It should not be a bug in the presets, as I set the environment to be used in windows-x64
base preset, which windows-ninja-clang-x64
inherits from (transitively).
[driver] Switching to configure preset: windows-ninja-clang-x64
[driver] Unsetting test preset
[driver] Switching to build preset: windows-ninja-clang-x64-debug
[driver] Switching to test preset: __defaultTestPreset__
[driver] Switching to package preset: __defaultPackagePreset__
[driver] Switching to workflow preset: __defaultWorkflowPreset__
[main] Configuring project: <scrubbed>
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe -DCMAKE_DIR=<scrubbed>\cmake -DCMAKE_INSTALL_PREFIX=<scrubbed>/out/install/windows-ninja-clang-x64 -S<scrubbed> -B<scrubbed>/out/build/windows-ninja-clang-x64 -G "Ninja Multi-Config"
[cmake] CMake Error: CMake was unable to find a build program corresponding to "Ninja Multi-Config". 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\CMake\bin\cmake.EXE" -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe -DCMAKE_DIR=<scrubbed>\cmake -DCMAKE_INSTALL_PREFIX=<scrubbed>/out/install/windows-ninja-clang-x64 -S<scrubbed> -B<scrubbed>/out/build/windows-ninja-clang-x64 -G "Ninja Multi-Config" exited with code: 1
Any chance this is related? Do you want me to open a new issue for this?
@jeremicmilan As a rule of thumb, it's easier to track and investigate issues when they are created by themselves (assuming it's not a duplicate). So, if you could, please create a new issue.
If this is working for Ninja + MSVC but not for clang, I tend to agree this is likely a bug, so hopefully you can provide a minimal repro when you create the new issue. Thanks!
@jeremicmilan As for when it might appear in the official release channel, we have a release schedule here: https://github.com/microsoft/vscode-cmake-tools/wiki/Release-schedule
@gcampbell-msft , the release version of the extension is now working way faster than before (2-3 seconds E2E compared to 10ish seconds from before). Previously there was a long delay after the following log entry:
[preset] Using developer environment from Visual Studio (instance 3d356f0c, version 17.9.34714.143, installed at "C:\Program Files\Microsoft Visual Studio\2022\Enterprise")
So, release version is more usable now, but it will be awesome to see your fix land as well, as then it's going to be super-fast!
Regarding the other issue, while I was trying to figure out the repro, I figured out that it happens in the pre-release version only (so I guess I started hitting it after I installed the version of the extension you shared). However, with your version, the issue happened only for Ninja+Clang, but in the pre-release version it happens for Ninja+MSVC as well. This is a serious issue, and I can't imagine it not being fixed until the release version. I guess pre-release version is very volatile, does it even make sense to file an issue for it?
@jeremicmilan Yes, if the failure is happening in the pre-release, this is actually all the more reason to file the issue, because we can then fix the issue before releasing a bug in the official release. Additionally, it will help give me full context, right now I don't fully understand what the issue you hit that is happening with Ninja + Clang. Thanks
@jeremicmilan I've quickly attempted to try to repro what you mentioned about the environment not being included for Ninja + MSVC, and I'm not sure I notice a difference between versions like 1.16.32 and the pre-release version, so any info you can provide so that we can investigate would be great. Thanks.
@gcampbell-msft, let me try and figure out minimal repro and create a new issue.
@jeremicmilan Correction, I think I've found the issue. Could you test this vsix? You'll have to change the extension from .zip to .vsix and install it manually.
If you can confirm that this fixes your issue, then I can merge the PR I have open for it: #3669, and it can fix the pre-release channel for you.
Tested it briefly (about 10-15 times over different projects) and it works perfectly and very quickly! Thank you for the quick fix!
I couldn't figure out minimal repro, as it seems it was not deterministic. Your linked PR shed some light on that.
Brief Issue Summary
When using ninja as a generator and when you change the configure preset it will automatically detect that ninja and cl are not in the path and it will load the appropriate vcvars, which is expected. However, after the change it will unload and reload every type of preset and for each preset type (configure, build, test, package, workflow). The expectation is for the vcvars (which is taking 5-10 seconds) to be ran only once per configure preset change, as the same Visual Studio development environment variables can be used for all presets. This behavior is significantly impacting the experience of doing builds with multiple compilers on Windows. For comparison on Linux, initializing all types of presets takes less than a second.
Debug Log
Relevant logs:
Additional Information
CMakePresets.json:
CMake Tools Diagnostics