Skip to content

Replace copy genrules with copy_file#30122

Draft
dzbarsky wants to merge 2 commits into
bazelbuild:masterfrom
dzbarsky:codex/replace-copy-genrules
Draft

Replace copy genrules with copy_file#30122
dzbarsky wants to merge 2 commits into
bazelbuild:masterfrom
dzbarsky:codex/replace-copy-genrules

Conversation

@dzbarsky

@dzbarsky dzbarsky commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Summary

Replace copy-only genrule targets with bazel_skylib copy_file targets for:

  • Bazel executable .exe aliases
  • the builtins zip resource redirect
  • the Starlark CPU profiler JNI library alias
  • JNI header and native library aliases

Each target permits symlinking, so copy_file creates a declared symlink action instead of invoking an ambient cp executable through a shell. This PR contains no third-party patch or dependency update.

This focused change is extracted from #30121 for independent review.

Motivation

The existing genrule targets assume the execution environment provides cp and a compatible shell. That assumption fails when Bazel runs on Windows while actions execute remotely on Linux. The dedicated copy_file rule also states the operation directly and removes repeated command strings.

Build API Changes

No.

Validation

  • buildifier -mode=check src/BUILD src/main/java/com/google/devtools/build/lib/bazel/rules/BUILD src/main/java/net/starlark/java/eval/BUILD src/main/native/BUILD
  • bazel aquery confirmed the expected Symlink or ExecutableSymlink action, input, and output for all nine generated targets
  • bazel build --jobs=2 //src/main/java/com/google/devtools/build/lib/bazel/rules:builtins_bzl_zip //src/main/java/net/starlark/java/eval:cpu_profiler_jni_darwin //src/main/native:copy_link_jni_header //src/main/native:copy_link_jni_md_header //src/main/native:mac-compat

Release Notes

RELNOTES: None

dzbarsky added 2 commits July 2, 2026 12:16
## Summary

- patch `rules_jvm_external` 6.8 so `jvm_import` runs
`AddJarManifestEntry_deploy.jar` with the Java runtime selected for the
execution platform
- avoid executing the generated `java_binary` Bash launcher directly
- use `%{label}` for the compile-JAR progress message

## Motivation

This is a follow-up to bazelbuild#29763 and currently includes that dependency
commit because the dependency branch lives in the contributor fork. The
exec-Java change is the second commit and can be rebased to `master`
once bazelbuild#29763 lands.

The patch restores the intent of
[rules_jvm_external#1059](bazel-contrib/rules_jvm_external#1059),
which was reverted by
[rules_jvm_external#1061](bazel-contrib/rules_jvm_external#1061)
after downstream Bazel worked around the issue using tool-Java
command-line flags.

Those flags are insufficient for a Windows host using Linux remote
execution. The generated `java_binary` launcher is a Bash script, and
Bazel may try to execute it as a Windows executable, failing with `%1 is
not a valid Win32 application` before Java starts.

Invoking the deploy JAR through the Java runtime toolchain avoids the
Bash wrapper entirely and makes manifest stamping and compile-JAR
creation executable on the selected execution platform.

The corresponding upstream `rules_jvm_external` change is
bazel-contrib/rules_jvm_external#1583.
Use bazel_skylib copy_file rules for Bazel executable aliases, the builtins zip resource redirect, Starlark and native JNI library aliases, and JNI header aliases.

Each target allows symlinking, so these copy-only operations no longer require an ambient cp executable or shell.
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.

1 participant