Breaking Change: Dropping support for Bazel+MSVC #20085

mkruskal-google · 2025-01-23T00:40:18Z

This issue is a placeholder for gathering feedback on an upcoming breaking change

Due to persistent issues with MSVC's path length limits, we've decided to drop support for Bazel in 34.0. Starting in 30.0, you will need to explicitly set a flag --define=protobuf_allow_msvc=true to use this combination. Our recommended alternative is clang-cl, which we will officially support going forward.

If you're not using Protobuf-C++ and you've hit this issue purely because you need to build protoc from source, just use the opt-out flag for now. We will be releasing a prebuilt protoc toolchain by 34.0, which should decouple you from this.

The text was updated successfully, but these errors were encountered:

An opt-out flag `--define=protobuf_allow_msvc=true` will be available until our 2026 breaking release 34.0. See #20085 for more details. #test-continuous PiperOrigin-RevId: 718525948

An opt-out flag `--define=protobuf_allow_msvc=true` will be available until our 2026 breaking release 34.0. See #20085 for more details. #test-continuous PiperOrigin-RevId: 720822739

As seen in the following thread, the protobuf team is planning to stop supporting the combination of Bazel and cl.exe due to well-known its path length limitation. * protocolbuffers/protobuf#20085 As a preparation before switching to protobuf v30 (google#1177), let's explicitly add a commandline option as explained to continue using this combination as a short term solution. This commit should have no impact on Probobuf v29.x.

As seen in the following thread, the protobuf team is planning to stop supporting the combination of Bazel and cl.exe due to well-known its path length limitation. * protocolbuffers/protobuf#20085 As a preparation before switching to protobuf v30 (#1177), let's explicitly add a commandline option as explained to continue using this combination as a short term solution. This commit should have no impact on Probobuf v29.x. PiperOrigin-RevId: 725882774

With this commit we start using 'clang-cl' to build Mozc for Windows with Bazel. While the original motivation of switching to 'clang-cl' is that protobuf is planning to stop supporting cl.exe with bazel build in protobuf v34 [1], but there is also an on-going build breakage that happens when combining protobuf and abseil-cpp 20250127.0, which is not yet fixed [2]. The latter one is more critical for us because more and more bzlmod dependencies start requiring abseil-cpp 20250127.0 or higher. There must be no impact on Windows GYP build. Closes google#1179. [1]: protocolbuffers/protobuf#20085 [2]: protocolbuffers/protobuf#20331

@crt-31

Keeps the `README` guidance in sync with what we're actually using in `WORKSPACE` for consistency's sake. @crt-31 and I found that the Windows build failure for bazel-contrib#1710 mentioned in the earlier commit is related to the Windows/MSVC file path length limit. `src/google/protobuf/compiler/java/java_features.pb.h`, the path specified in the error message, doesn't exist until `protobuf` v25.0. - protocolbuffers/protobuf#12947 Furthermore, the Protobuf team currently plans to just drop MSVC support: - https://protobuf.dev/news/v30/#poison-msvc--bazel - protocolbuffers/protobuf#20085 I plan to experiment again with "Protobuf Toolchainization", which I'd tried in October when beginning the Bzlmod experiment. Here are some interesting background resources before I dig in on that: - bazelbuild/rules_proto#213 - bazelbuild/rules_proto#179 - https://github.com/bazelbuild/rules_proto/releases/tag/6.0.0 - https://github.com/aspect-build/toolchains_protoc/ - protocolbuffers/protobuf#20182 - protocolbuffers/protobuf#19679 - protocolbuffers/protobuf#19558

Registers a precompiled protocol compiler toolchain when `--incompatible_enable_proto_toolchain_resolution` is `True`. Part of bazel-contrib#1482 and bazel-contrib#1652. Stops `protoc` recompilation, and fixes the build breakage in bazel-contrib#1710 due to `protobuf` include paths exceeding the Visual Studio path length limit. The updates to `scala_proto/scala_proto_toolchain.bzl` were inspired by: - protocolbuffers/protobuf: bazel: Remove hardcoded dependency on //:protoc from language runtimes #19679 protocolbuffers/protobuf#19679 The `proto_lang_toolchain` call was inspired by the `README` from: - https://github.com/aspect-build/toolchains_protoc/ Adds `scripts/update_protoc_integrity.py` to automatically update `scala/private/protoc/protoc_integrity.bzl`. This should make builds of `rules_scala` much faster all around. Given the fact that this feature depends on recent `protobuf` versions, and the Windows `protobuf` build breaks without it, we have a catch-22. It likely can't be separated from the rest of bazel-contrib#1710, though I would prefer that. It also seems likely that we'd eventually need to do this to continue supporting Windows, per: - protocolbuffers/protobuf#12947 - https://protobuf.dev/news/v30/#poison-msvc--bazel - protocolbuffers/protobuf#20085 More background on proto toolchainization: - Proto Toolchainisation Design Doc https://docs.google.com/document/d/1CE6wJHNfKbUPBr7-mmk_0Yo3a4TaqcTPE0OWNuQkhPs/edit - bazelbuild/bazel: Protobuf repo recompilation sensitivity bazelbuild/bazel#7095 - bazelbuild/rules_proto: Implement proto toolchainisation bazelbuild/rules_proto#179 - rules_proto 6.0.0 release notes mentioning Protobuf Toolchainisation https://github.com/bazelbuild/rules_proto/releases/tag/6.0.0

With this commit we start using 'clang-cl' to build Mozc for Windows with Bazel. While the original motivation of switching to 'clang-cl' is that protobuf is planning to stop supporting cl.exe with bazel build in protobuf v34 [1], there is also an on-going build breakage that happens when combining protobuf and abseil-cpp 20250127.0, which is not yet fixed [2]. The latter one is more critical for us because more and more bzlmod dependencies start requiring abseil-cpp 20250127.0 or higher. There must be no impact on Windows GYP build. Closes google#1179. [1]: protocolbuffers/protobuf#20085 [2]: protocolbuffers/protobuf#20331

With this commit we start using 'clang-cl' to build Mozc for Windows with Bazel. While the original motivation of switching to 'clang-cl' is that protobuf is planning to stop supporting cl.exe with bazel build in protobuf v34 [1], there is also an on-going build breakage that happens when combining protobuf and abseil-cpp 20250127.0, which is not yet fixed [2]. The latter one is more critical for us because more and more bzlmod dependencies start requiring abseil-cpp 20250127.0 or higher. There must be no impact on Windows GYP build. Closes #1179. [1]: protocolbuffers/protobuf#20085 [2]: protocolbuffers/protobuf#20331 PiperOrigin-RevId: 736417401

mattip · 2025-03-18T12:48:53Z

I maintain the ray bazel build for windows. Ray uses protobuf and many other components. How can I tell the monolithic bazel build of ray "use clang-cl for protobuf only"?

A bit more context: ray uses bazel 6.5.0 and is slow to upgrade. It also has boost as a component, boost uses assembly files that do not build with clang-cl.

jbms · 2025-04-02T16:36:56Z

Please reconsider dropping support. While I am well aware that supporting Bazel+MSVC is frustrating, Protobuf is a transitive dependency of a massive number of projects, and especially a large fraction of Google-owned open source projects, including gRPC, TensorFlow, Google Cloud C++ SDK, TensorStore, etc. This change will force a very large number of projects to stop supporting MSVC with Bazel, and may prevent some from building with Windows at all.

Building with a mixed toolchain (MSVC for some targets, clang-cl for others) within a workspace is unlikely to be practical anyway, but given that the issues tend to be with headers it is unlikely to help even if it were practical.

To address the following issue found in bazelbuild/bazel-central-registry#4269 ``` bazel-out/x64_windows-opt-exec-ST-d57f47055a04/bin/external/protobuf~/src/google/protobuf/stubs/_virtual_includes/lite\google/protobuf/stubs/port.h(38): fatal error C1189: #error: "Protobuf will be dropping support for MSVC + Bazel in 34.0. To continue using it until then, use the flag --define=protobuf_allow_msvc=true. For feedback or discussion, see github.com/protocolbuffers/protobuf/issues/20085." ``` This is a short-term fix to unblock the BCR release. Long-term solution is to change it to use clang on Windows.

mkruskal-google added 30.x bazel windows labels Jan 23, 2025

copybara-service bot mentioned this issue Jan 23, 2025

Breaking change: prohibit using Bazel+MSVC to build protobuf #20082

Merged

yukawa mentioned this issue Feb 9, 2025

Update third_party/protobuf to v30.0 google/mozc#1177

Closed

yukawa mentioned this issue Feb 9, 2025

Enable to build protobuf v30 with Bazel+MSVC google/mozc#1178

Merged

This was referenced Feb 9, 2025

See if we can use clang-cl to build Mozc for Windows with Bazel google/mozc#1179

Closed

clang-cl toolchain for x86 (32-bit) binaries is missing bazelbuild/rules_cc#358

Open

Support clang-cl to build x86 binaries bazelbuild/rules_cc#360

Open

yukawa mentioned this issue Feb 26, 2025

Start using clang-cl for Windows Bazel build google/mozc#1198

Merged

mbland mentioned this issue Mar 1, 2025

Bazel 8 + rules_java 8 updates, protoc toolchain bazel-contrib/rules_scala#1710

Merged

esrauchg mentioned this issue Mar 3, 2025

src build on windows not working #12947

Open

mbland mentioned this issue Mar 4, 2025

Support Bzlmod and add rules_scala to bazel-central-registry bazel-contrib/rules_scala#1482

Open

laramiel mentioned this issue Apr 2, 2025

Alternative _virtual_includes organization to solve MSVC issues bazelbuild/bazel#18683

Open

mbland mentioned this issue Apr 30, 2025

bazel: Remove hardcoded dependency on //:protoc from language runtimes #19679

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Breaking Change: Dropping support for Bazel+MSVC #20085

Breaking Change: Dropping support for Bazel+MSVC #20085

mkruskal-google commented Jan 23, 2025 •

edited

Loading

mattip commented Mar 18, 2025 •

edited

Loading

jbms commented Apr 2, 2025

Breaking Change: Dropping support for Bazel+MSVC #20085

Breaking Change: Dropping support for Bazel+MSVC #20085

Comments

mkruskal-google commented Jan 23, 2025 • edited Loading

mattip commented Mar 18, 2025 • edited Loading

jbms commented Apr 2, 2025

mkruskal-google commented Jan 23, 2025 •

edited

Loading

mattip commented Mar 18, 2025 •

edited

Loading