-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass ct.sym
to direct version of Turbine
#20294
Conversation
5dea561
to
fa11afa
Compare
@cushon I am slightly confused why the integration test still fails - it does seem to pass the correct argument to turbine. But it looks like the |
This looks great overall.
I am not sure, @hvadehra do you know? |
It's also run for java_tools built from source, but only run while creating the java_tools release: Options: I guess a) is slightly better, since we will exercise the test in this PR, rather than during the java_tools release. But I'm okay with either option. |
src/main/java/com/google/devtools/build/lib/rules/java/JavaToolchainTool.java
Show resolved
Hide resolved
fa11afa
to
e54ae09
Compare
This ensures that Turbine has access to `ct.sym` and thus supports the `--release` flag even if it is compiled into a Graal native image, which doesn't have access to a `JAVA_HOME`. This requires exposing the `ct.sym` file on a new `lib_ct_sym` attribute of `java_runtime` and passing it into Turbine via the `turbine.ctSymPath` system property introduced in v0.3.1.
dbdfc95
to
7648e0a
Compare
7648e0a
to
8bdff69
Compare
I think that's not true, this test also used to run with Java tools built from HEAD: bazel/src/test/shell/bazel/BUILD Lines 264 to 275 in 7d10999
I investigated this further and am now convinced that the mechanism used to override the remote Java and coverage tools simply stopped working when |
src/main/java/com/google/devtools/build/lib/rules/java/JavaToolchainTool.java
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/rules/java/JavaToolchainTool.java
Show resolved
Hide resolved
@@ -24,36 +24,34 @@ source "${CURRENT_DIR}/coverage_helpers.sh" \ | |||
|| { echo "coverage_helpers.sh not found!" >&2; exit 1; } | |||
|
|||
|
|||
RULES_JAVA_REPO_NAME=$(cat "$(rlocation io_bazel/src/test/shell/bazel/RULES_JAVA_REPO_NAME)") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The mechanism used to override the remote Java and coverage tools didn't work with --enable_bzlmod
, so I rewrote it borrowing some existing tricks like this one.
@meteorcloudy Could you review the changes to the test files (except for the new test case, which is unrelated to Bzlmod)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@bazel-io flag |
Yes, you're quite right, I was too hasty in reading the BUILD file :)
Thanks a lot for taking the time to fix this. @meteorcloudy We should probably audit all other tests that use a similar repo overridding mechanism to ensure they're still working as expected with bzlmod enabled. @fmeum Do your changes not break the tests when making the java_tools release ( |
Yes, I have tracking issue for enabling Bzlmod in all tests. #19824. For shell tests, those are the leftovers: https://cs.opensource.google/search?q=%22disable_bzlmod%22&sq=&ss=bazel |
Good catch, I pushed a new commit to hopefully fix this. |
@bazel-io fork 7.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for Bzlmod related change.
@@ -24,36 +24,34 @@ source "${CURRENT_DIR}/coverage_helpers.sh" \ | |||
|| { echo "coverage_helpers.sh not found!" >&2; exit 1; } | |||
|
|||
|
|||
RULES_JAVA_REPO_NAME=$(cat "$(rlocation io_bazel/src/test/shell/bazel/RULES_JAVA_REPO_NAME)") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thank you for addressing this. I built the binary from bazel@HEAD (I made sure the commit 4a29f08 was there) but still see this problem happening. I might be doing something wrong. $ /path/to/bazel/bazel-bin/src/bazel build //:foo --sandbox_debug
...
ERROR: /private/var/tmp/_bazel_honnix/7a71ac7a78af123987d625ef3d1d3eec/external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/BUILD:1:13: Compiling Java headers external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/librules_jvm_external-hjar.jar (4 source files) [for tool] failed: (Exit 1): sandbox-exec failed: error executing Turbine command
(cd /private/var/tmp/_bazel_honnix/7a71ac7a78af123987d625ef3d1d3eec/sandbox/darwin-sandbox/866/execroot/_main && \
exec env - \
LC_CTYPE=en_US.UTF-8 \
PATH='...' \
TMPDIR=/var/folders/bd/4b4zq6s56tg01zdzqpw5b9gm0000gn/T/ \
/usr/bin/sandbox-exec -f /private/var/tmp/_bazel_honnix/7a71ac7a78af123987d625ef3d1d3eec/sandbox/darwin-sandbox/866/sandbox.sb /var/tmp/_bazel_honnix/install/0f4666cf1082ebd83b24dc6a797d2675/process-wrapper '--timeout=0' '--kill_delay=15' '--stats=/private/var/tmp/_bazel_honnix/7a71ac7a78af123987d625ef3d1d3eec/sandbox/darwin-sandbox/866/stats.out' external/rules_java~7.3.0~toolchains~remote_java_tools_darwin_arm64/java_tools/turbine_direct_graal '-Dturbine.ctSymPath=external/rules_java~7.3.0~toolchains~remotejdk21_macos_aarch64/lib/ct.sym' --output bazel-out/darwin_arm64-opt-exec-ST-13d3ddad9198/bin/external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/librules_jvm_external-hjar.jar --output_deps bazel-out/darwin_arm64-opt-exec-ST-13d3ddad9198/bin/external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/librules_jvm_external-hjar.jdeps --bootclasspath bazel-out/darwin_arm64-opt-exec-ST-13d3ddad9198/bin/external/rules_java~7.3.0/toolchains/platformclasspath.jar --sources external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/ByteStreams.java external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/Coordinates.java external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/Hasher.java external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/MavenRepositoryPath.java --javacopts -source 17 -target 17 '-XDskipDuplicateBridges=true' '-XDcompilePolicy=simple' -g -parameters -Xep:ReturnValueIgnored:OFF -Xep:IgnoredPureGetter:OFF -Xep:EmptyTopLevelDeclaration:OFF -Xep:LenientFormatStringValidation:OFF -Xep:ReturnMissingNullable:OFF -Xep:UseCorrectAssertInTests:OFF --release 8 -- --target_label @@@rules_jvm_external//private/tools/java/com/github/bazelbuild/rules_jvm_external:rules_jvm_external --reduce_classpath_mode NONE)
java.lang.NullPointerException: attempted to use --release, but JAVA_HOME is not set
at java.base@20.0.2/java.util.Objects.requireNonNull(Objects.java:259)
at com.google.turbine.binder.CtSymClassBinder.bind(CtSymClassBinder.java:52)
at com.google.turbine.main.Main.bootclasspath(Main.java:309)
at com.google.turbine.main.Main.compile(Main.java:142)
at com.google.turbine.main.Main.compile(Main.java:133)
at com.google.turbine.main.Main.main(Main.java:89)
Target //:foo failed to build I built bazel as |
@honnix Bazel uses a prebuilt version of Turbine that is shipped separately. This will require an update to the java_tools and ship with the next release of rules_java. |
Ah I see. Thank you. I will wait until then. I can temporarily disable header compilation. |
Cherry-picked from 4a29f08 Compared to the cherry-picked commit, this does not contain the turbine update as turbine is not embedded into the Bazel binary and can be updated independently via rules_java. Original description follows: This ensures that Turbine has access to `ct.sym` and thus supports the `--release` flag even if it is compiled into a Graal native image, which doesn't have access to a `JAVA_HOME`. This requires exposing the `ct.sym` file on a new `lib_ct_sym` attribute of `java_runtime` and passing it into Turbine via the `turbine.ctSymPath` system property introduced in v0.3.1. Along the way this commit fixes the setup code for testing unreleased versions of the remote Java and coverage tools, which silently broke with the flip of `--enable_bzlmod`. Work towards bazelbuild/stardoc#195 Closes bazelbuild#20294. PiperOrigin-RevId: 585866870 Change-Id: I416b787e324bd3a01e223edbda4f9ba137c21241
Cherry-picked from 4a29f08 Compared to the cherry-picked commit, this does not contain the turbine update as turbine is not embedded into the Bazel binary and can be updated independently via rules_java. Original description follows: This ensures that Turbine has access to `ct.sym` and thus supports the `--release` flag even if it is compiled into a Graal native image, which doesn't have access to a `JAVA_HOME`. This requires exposing the `ct.sym` file on a new `lib_ct_sym` attribute of `java_runtime` and passing it into Turbine via the `turbine.ctSymPath` system property introduced in v0.3.1. Along the way this commit fixes the setup code for testing unreleased versions of the remote Java and coverage tools, which silently broke with the flip of `--enable_bzlmod`. Work towards bazelbuild/stardoc#195 Closes bazelbuild#20294. PiperOrigin-RevId: 585866870 Change-Id: I416b787e324bd3a01e223edbda4f9ba137c21241
Cherry-picked from 4a29f08 Compared to the cherry-picked commit, this does not contain the turbine update as turbine is not embedded into the Bazel binary and can be updated independently via rules_java. Original description follows: This ensures that Turbine has access to `ct.sym` and thus supports the `--release` flag even if it is compiled into a Graal native image, which doesn't have access to a `JAVA_HOME`. This requires exposing the `ct.sym` file on a new `lib_ct_sym` attribute of `java_runtime` and passing it into Turbine via the `turbine.ctSymPath` system property introduced in v0.3.1. Along the way this commit fixes the setup code for testing unreleased versions of the remote Java and coverage tools, which silently broke with the flip of `--enable_bzlmod`. Work towards bazelbuild/stardoc#195 Closes #20294. PiperOrigin-RevId: 585866870 Change-Id: I416b787e324bd3a01e223edbda4f9ba137c21241 Closes #20323
@keertk Could you create patch releases of java_tools and rules_java from current HEAD? |
@fmeum Just to clarify, Bazel 7 doesn't have to wait for the new releases, right? |
Exactly, with this PR merged it is fully independent. |
@fmeum yes sure, though this is currently blocked by the ongoing network issues. |
…ting that overriding actually works Should help avoid issues like: #21351 #20374 #20294 (comment) Closes #21364. PiperOrigin-RevId: 607785065 Change-Id: Ib8c75d597911034091c3dafd638acfe72d2eb9c5
This ensures that Turbine has access to
ct.sym
and thus supports the--release
flag even if it is compiled into a Graal native image, which doesn't have access to aJAVA_HOME
.This requires exposing the
ct.sym
file on a newlib_ct_sym
attribute ofjava_runtime
and passing it into Turbine via theturbine.ctSymPath
system property introduced in v0.3.1.Along the way this commit fixes the setup code for testing unreleased versions of the remote Java and coverage tools, which silently broke with the flip of
--enable_bzlmod
.Work towards bazelbuild/stardoc#195