fix: convert relative symlinks in test_module_repo to absolute #2350
+36
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jjmaestro
requested review from
fweikert,
meteorcloudy and
Wyverald
as code owners
|
@meteorcloudy (or other reviewers) could you please have a look at this? Thanks! |
|
Sorry for another ping, but I'd really love if this PR landed, I think it fixes a whole set of problems on Windows that do affect Bazel modules like mine in bazelbuild/bazel-central-registry#5205 :) Could any of you have a look? It's a pretty straight-forward change. Thanks!! |
|
cc @Wyverald as BCR expert |
|
@Wyverald I'd love if you could have a look and review the PR! 🙏 Thanks!! |
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Aug 11, 2025
Resolves the Windows symlink breakage from bazelbuild/bazel-central-registry#5490 by replacing examples/crossbuild/protobuf.patch with a full copy. Bumps rules_python to 1.5.2 for both Bzlmod and legacy WORKSPACE builds. --- This is hopefully a temporary measure to unblock the next `rules_scala` release. This will probably require creating a v7.1.1 tag to trigger a new .bcr/presubmit.yml workflow. See bazelbuild/bazel-central-registry#5506 for details about the breakage. If and when bazelbuild/continuous-integration#2350 lands and makes its way to the BCR presubmit build, we could restore the symlink. Better yet, if protocolbuffers/protobuf#19679 ever lands, we could remove this symlink and all the others. Bumped `rules_python` to 1.5.2 for legacy `WORKSPACE` builds because it contains bazel-contrib/rules_python#3134, which fixes bazel-contrib/rules_python#3119.
jjmaestro
force-pushed
the
fix-bcr_presubmit-relative-links
branch
from
fc9280d to
c8e4fa5
Compare
meteorcloudy
requested changes
Aug 12, 2025
Although relative links are valid in Windows, it seems that they fail under some circumstances. For example, see bazelbuild/bazel-central-registry#5205
jjmaestro
force-pushed
the
fix-bcr_presubmit-relative-links
branch
from
c8e4fa5 to
772c909
Compare
simuons
pushed a commit
to bazel-contrib/rules_scala
that referenced
this pull request
Aug 14, 2025
Resolves the Windows symlink breakage from bazelbuild/bazel-central-registry#5490 by replacing examples/crossbuild/protobuf.patch with a full copy. Bumps rules_python to 1.5.2 for both Bzlmod and legacy WORKSPACE builds. --- This is hopefully a temporary measure to unblock the next `rules_scala` release. This will probably require creating a v7.1.1 tag to trigger a new .bcr/presubmit.yml workflow. See bazelbuild/bazel-central-registry#5506 for details about the breakage. If and when bazelbuild/continuous-integration#2350 lands and makes its way to the BCR presubmit build, we could restore the symlink. Better yet, if protocolbuffers/protobuf#19679 ever lands, we could remove this symlink and all the others. Bumped `rules_python` to 1.5.2 for legacy `WORKSPACE` builds because it contains bazel-contrib/rules_python#3134, which fixes bazel-contrib/rules_python#3119.
|
Merging this right now, let's monitor the BCR presubmit closely in case of any breakage. |
|
@meteorcloudy once it's merged and deployed, you can "test it in prod" by re-launching the checks for bazelbuild/bazel-central-registry#5205 :D With this fix, it should all be green (I hope!) |
|
Hmm, looks like we still have the same issue: https://buildkite.com/bazel/bcr-presubmit/builds/18095#0198a912-4555-4d0b-8685-25cd781dc75f |
|
Oh, I didn't actually merge this one.. 🤦🏻♂️ |
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Although relative links are valid in Windows, it seems that they fail under some circumstances. For example, see
bazelbuild/bazel-central-registry#5205