Skip to content

Conversation

@mbland
Copy link
Contributor

@mbland mbland commented Jun 13, 2025

Commit 73401b0 updated bazel-contrib/rules_jvm_external to 6.5 in MODULE.bazel for v31.0, but missed it in //:protobuf_deps.bzl. This caused WORKSPACE builds to break under Bazel 8.2.1 with rules_java 8.12.0 and --incompatible_autoload_externally=:

Confirmed that this change fixes the breakage when building the following target in bazel-contrib/rules_scala:

USE_BAZEL_VERSION=8.2.1 bazel build \
  --noenable_bzlmod --enable_workspace \
  --incompatible_autoload_externally= \
  //test/proto/custom_generator:failing_scala_proto_deps_toolchain_def

Commit 73401b0 updated bazel-contrib/rules_jvm_external to 6.5 in
`MODULE.bazel` for v31.0, but missed it in `//:protobuf_deps.bzl`. This
caused `WORKSPACE` builds to break under Bazel 8.2.1 with `rules_java`
8.12.0 and `--incompatible_autoload_externally=`:

- protocolbuffers#19129 (comment)

Confirmed that this change fixes the breakage when building the
following target in bazel-contrib/rules_scala:

```
USE_BAZEL_VERSION=8.2.1 bazel build \
  --noenable_bzlmod --enable_workspace \
  --incompatible_autoload_externally= \
  //test/proto/custom_generator:failing_scala_proto_deps_toolchain_def
```
@zhangskz zhangskz added the 🅰️ safe for tests Mark a commit as safe to run presubmits over label Jun 13, 2025
@github-actions github-actions bot removed the 🅰️ safe for tests Mark a commit as safe to run presubmits over label Jun 13, 2025
@mkruskal-google mkruskal-google added the 🅰️ safe for tests Mark a commit as safe to run presubmits over label Jun 13, 2025
@github-actions github-actions bot removed the 🅰️ safe for tests Mark a commit as safe to run presubmits over label Jun 13, 2025
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
simuons pushed a commit to bazel-contrib/rules_scala that referenced this pull request Aug 18, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from #1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants