protobuf is dropping support for Bazel and MSVC

[sluongng]

protocolbuffers/protobuf#20085
https://protobuf.dev/news/2025-01-23/

This is a bit concerning for longer-term Windows support for Bazel.

Is there something we can do on Bazel's side to help with the long-path problem?

[fmeum]

As long as we get both prebuilt binaries and clang-cl support by the time support is fully dropped, that may not be so bad. The former helps when compiling protoc is the only thing you need a C++ toolchain for, the latter is probably not hard for folks that are already invested in C++ on Windows.

Cc @peakschris

[peakschris]

The company I work for has a strategic initiative with Microsoft, and I have asked our contacts there if they can address the path length issue in cl.exe (it impacts our own product build), and they have asked the compiler team and the answer came back as essentially no - it's too baked into their code to prioritize.

[peakschris]

We cannot drop MSVC for our own product builds. We don't require protobuf. But it is required in our MODULE.bazel file to keep various bazel rulesets happy. Will we be impacted by this?

[peakschris]

It's worth noting that bazel could work around this issue with cl.exe if it was a priority:

• Alternative _virtual_includes organization to solve MSVC issues #18683
• MSVC tools don't support long paths #19616

[fmeum]

If you are okay with a prebuilt protoc binary and the protobuf time delivers it in time, you should not be impacted. Thanks for confirming that asking Microsoft to please fix their compiler won't help in the short to mid term.