-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bazel C/C++ toolchain autodetection fails with newest version of Visual Studio on Windows (17.6.2) due to new directory layout #18592
Comments
hmm, maybe relying on the year being in the path is not a good idea, seen that you can change the installation directory from the default, including that bit of the path. |
There is a bazel bug that is affecting the windows-latest runners for github workflows. More details at actions/runner-images#7675 and bazelbuild/bazel#18592
Here's my rough shot at a fix, though I'm not entirely sure how to add tests for it |
This seems to be affected in Bazel 5 as well, and has broken our CI (we need to support 5 and 6): actions/runner-images#7662 |
I've noticed no prior changes to the autoconfiguration included any kind of tests, so I'm marking my PR as ready for review, after trying it out locally. I've also noticed that all Windows CI checks currently use VS 2019. It might probably be a good idea to add or switch to VS 2022. As a temporary workaround that I used to compile bazel itself, one can go as admin into the |
beware that Visual Studio 2022 Community and Enterprise are not the same (FYI github runner and this user is using |
Yes, but both actually exhibit the same behaviour and work with the same workaround of moving the |
FYI, I think there is another workaround: |
Windows 2022 is not well supported by bazel yet: bazelbuild/bazel#18592
* Downgrade bazel to windows-2019 Windows 2022 is not well supported by bazel yet: bazelbuild/bazel#18592 * no windows-latest, only windows-2019 (for bazel)
This is the same PR as bazelbuild#18608 but extended by the modification proposed by @meteorcloudy This should fix bazelbuild#18592 Should also be picked to 6.3.0 -> bazelbuild#18799 Closes bazelbuild#18945. PiperOrigin-RevId: 548725707 Change-Id: Iff0f972c9fc23491c8070ee2b12ec600a3d1ead9
This is the same PR as #18608 but extended by the modification proposed by @meteorcloudy This should fix #18592 Should also be picked to 6.3.0 -> #18799 Closes #18945. PiperOrigin-RevId: 548725707 Change-Id: Iff0f972c9fc23491c8070ee2b12ec600a3d1ead9 Co-authored-by: Vertexwahn <[email protected]>
The Bazel versions under test currently fail to detect Visual Studio 2022, see bazelbuild/bazel#18592. This is only fixed in Bazel 6.3.0.
Since Bazel 6.3, Visual C++ 2022 should be supported. See bazelbuild/bazel#18592 and bazelbuild/bazel#18960.
Since Bazel 6.3, Visual C++ 2022 should be supported. See bazelbuild/bazel#18592 and bazelbuild/bazel#18960.
Due to bazelbuild/bazel#18592 PiperOrigin-RevId: 629440300
Due to bazelbuild/bazel#18592 PiperOrigin-RevId: 629440300
Due to bazelbuild/bazel#18592 PiperOrigin-RevId: 629440300
Due to bazelbuild/bazel#18592 PiperOrigin-RevId: 629440300
Due to bazelbuild/bazel#18592 PiperOrigin-RevId: 629440300
Due to bazelbuild/bazel#18592 PiperOrigin-RevId: 629459786
Description of the bug:
When running C/C++ builds on Windows with autodetection where the most recent version of Visual Studio Enterprise is installed (version 17.6.2), the build fails with
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
//examples/cpp:hello-world
in the bazel repo itself)Which operating system are you running Bazel on?
Windows
What is the output of
bazel info release
?release 6.2.1
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
By debugging I've traced back this behaviour to this _is_vs_2017_or_2019 function
Apart from the misname (it's supposed to actually check whether the release year is greater than 2017, including 2022), the problem is that a recent addition to VS has added a fourth
vcpkg
directory in theVC
directory, that throws the check off.The check could be updated to include the presence of this
vcpkg
directory, but I wonder whether there wouldn't be a more solid alternative robust to similar changes in the future. Maybecould work better? I can whip up a PR if this seems like a good idea.
The text was updated successfully, but these errors were encountered: