Skip to content

Bazel C/C++ toolchain autodetection fails with newest version of Visual Studio on Windows (17.6.2) due to new directory layout #18592

@redsun82

Description

@redsun82

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

Auto-Configuration Error: Cannot find VCVARSALL.BAT script under C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

  • Install latest Visual Studio (I did not try with the build tools version though), at least 17.6.2
  • Compile any dummy C/C++ project not using any kind of custom toolchain (for example, //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 returns development 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 the VC 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. Maybe

def _is_vs_2017_or_later(repository_ctx, vc_path):
    # example path C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC
    release_year = int(repository_ctx.path(vc_path).dirname.dirname.basename)
    return release_year >= 2017

could work better? I can whip up a PR if this seems like a good idea.

Metadata

Metadata

Assignees

Labels

P1I'll work on this now. (Assignee required)area-WindowsWindows-specific issues and feature requeststeam-Rules-CPPIssues for C++ rulestype: bug

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions