--host_javabase option expects a label and is non portable #6012
Comments
|
Once Java 11 is supported (#5723) it will be possible to do this with the default toolchain, and won't require setting a custom In the interim, you could do something like: And then build with: Other options include vendoring a JDK into your repository, or fetching JDK 11 from a remote repository instead of using a locally installed version. |
Thanks for the workround. Another non intrusive way to support alternative JDKs would be to teach Bazel to induce the custom JDK from $JAVA_HOME (like other build tools are doing): $ JAVA_HOME=/usr/lib64/jvm/java-11 bazel build --some-fancy-option-to-induce-custom-jdk-from-java-home :release
Git is unsuitable for versioning binaries, and network bandwidth is very valuable resources, so that I rule out that option. |
We're specifically not doing that by default so the non-VanillaJavaBuilder toolchain can rely on the embedded JDK instead of whatever the local JDK happens to be, to make sure it has a JDK 10. But it's fair to say there are some open questions about the best approach going forward. |
|
To close the loop on this, Line 27 in 5f432e0 |
|
That's nice, thanks. Given that discussion on repo-discuss mailing list: [1] I'm looking for an option to build Gerrit on stable branches and older tags, where Dagger DI and auto-value still have outdated versions, that are not compatible with JDK9 javac because of removal of So my question is there an easy way to build gerrit say v2.15 tag with Bazel@HEAD using @bazel_tools//tools/jdk:absolute_javabase? Other options? To reproduce the problem with Bazel@HEAD (a3ae3e2) checkout v2.15 tag and run: It worth noting that there are other incompatible changes, like: So that building of |
|
It sounds like #5984 would help here a bit. @lberki there's a higher-level question about the compatibility guarantees when using the latest Bazel to compile old release branches. It don't think there are any guarantees that will work (at least for pre-1.0 Bazel versions), given: https://groups.google.com/d/topic/bazel-discuss/wYocSoGTJOg/discussion. The only thing I can think of that would definitely work is to use an old Bazel version corresponding to the version of the code you're using, or even to check the version of Bazel into your repository. |
Yeah exactly! Just figured it out, that with this diff: diff --git a/BUILD b/BUILD
index 722e240851..810cb296f5 100644
--- a/BUILD
+++ b/BUILD
@@ -3,6 +3,23 @@ package(default_visibility = ["//visibility:public"])
load("//tools/bzl:genrule2.bzl", "genrule2")
load("//tools/bzl:pkg_war.bzl", "pkg_war")
+load(
+ "@bazel_tools//tools/jdk:default_java_toolchain.bzl",
+ "default_java_toolchain",
+)
+
+filegroup(
+ name = "vanillajavabuilder",
+ srcs = ["@bazel_tools//tools/jdk:VanillaJavaBuilder_deploy.jar"],
+)
+
+default_java_toolchain(
+ name = "toolchain_vanilla",
+ forcibly_disable_header_compilation = True,
+ javabuilder = [":vanillajavabuilder"],
+ jvm_opts = [],
+)
+
genrule(
name = "gen_version",
outs = ["version.txt"],That is actually the content of my pending PR (that was based on your suggestion actually) and voilá: Unfortunately I still have to patch |
Another limitation: we cannot install multiple Bazel versions in the moment easily (or am I missing something?): after installing of bazel version |
|
Temporarily I added this to Gerrit in root BUILD file: this caused the CI: [1] to fail with: That's because we are building //... on the CI. In fact the CI still uses Java 8. [1] https://gerrit-ci.gerritforge.com/job/Gerrit-verifier-bazel/54129/consoleText |
|
If the issue is just avoiding building that target when you do
|
|
Thank you! I will upload new CL with |
|
OK, that didn't work: And |
|
Sorry, Once you can use the In the interim, I have a hack that works around it by putting the variable reference behind a |
|
Thank you. |
Bazel@HEAD doesn't support Java 10 any more. The tool chain is extended
to support building with Java 10 using host_javabase option and vanilla
java builder. To use --host_javabase option we have to provide absolute
path to the JDK 10. To keep that non-portable part out of the build file
we use variable that is substitued during build invocation. Say, the
location of the JDK 10 is: /usr/lib64/jvm/java-10, then the build is
invoked with:
$ bazel build --host_javabase=:absolute_javabase \
--define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/java-10 ...
Given that absolute_javabase rule is not a part of released Bazel yet,
but will be only included in future Bazel releases, we have to add it in
our own build file:
java_runtime(
name = "absolute_javabase",
java_home = "$(ABSOLUTE_JAVABASE)",
visibility = ["//visibility:public"],
)
While this works, it fails the Gerrit-CI, because recently it was
changed to exercise //... rule, and cannot resolve ABSOLUTE_JAVABASE
variable, because it wasn't provided in the CI environment. CI is still
using Java 8.
One approach to address that problem would be to use "manual" tag for a
rule that would exclude it from generic targets like //..., but
unfortunately, java_runtime rule doesn't expose tag attribute.
The next workaround is to hide that variable behind a select statement.
This is a harmless hack:
config_setting(
name = "use_absolute_javabase",
values = {"define": "USE_ABSOLUTE_JAVABASE=true"},
)
java_runtime(
name = "absolute_javabase",
java_home = select({
":use_absolute_javabase": "$(ABSOLUTE_JAVABASE)",
"//conditions:default": "",
}),
visibility = ["//visibility:public"],
)
Now from the CI the rule: //:absolute_javabase would produce non working
java_runtime, because java_home wasn't specified, but given that this
java_runtime is not used during the build, it doesn't matter. Add also
a TODO comment to replace that interim solution when absolute_javabase
is supported in released Bazel version. As the consequence for hiding
that rule behind a condition, we need to provide additional variable so
that Bazel can correctly resolve java_home in java_runtime rule:
$ bazel build --host_javabase=:absolute_javabase \
--define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/java-10 \
--define=USE_ABSOLUTE_JAVABASE=true [...]
Also extend tools/eclipse/project.py to accept Java 10 specific options.
There is already --java <jdk number> option that was added recently to
support Eclipse .classpath generation when JDK 9 is used, but this can
not be used, because for Java 10 we have to provide absolute path to the
Java 10 location. Add new option --edge_java where all Java 10 specific
options can be passed:
$ tools/eclipse/project.py --edge_java \
"--host_javabase=:absolute_javabase \
--define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/java-10 \
--define=USE_ABSOLUTE_JAVABASE=true \
--host_java_toolchain=//:toolchain_vanilla \
--java_toolchain=//:toolchain_vanilla"
Alternative approach would be to add those options to Bazel resource
file.
Test Plan:
$ bazel build --host_javabase=:absolute_javabase \
--define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/java-10 \
--define=USE_ABSOLUTE_JAVABASE=true \
--host_java_toolchain=//:toolchain_vanilla \
--java_toolchain=//:toolchain_vanilla \
:release
and replace ABSOLUTE_JAVABASE variable with the location of JDK 10.
To verify that major version of generated classes is 54, use:
$ $JAVA_HOME/bin/javap -verbose \
-cp bazel-bin/java/com/google/gerrit/common/libserver.jar \
com.google.gerrit.common.data.ProjectAccess | grep "major version"
54
[1] bazelbuild/bazel#6012
Change-Id: I5e652f7a19afbcf3607febd9a7a165dc07918bd0
I would like to support custom JDK versions (e.g. JDK11) using
VanillaJavaBuilder, usingdefault_java_toolchainand leaving the source/target/bootclasspath unset.To make it work I have to pass custom jdk through a label to
--host_javabase, e.g. on Linux:It could be simplified to set that up and I uploded this PR to expose
toolchain_vanillain core Bazel, but the main problem remains: I have to specify path to/usr/lib64/jvm/java-11build file, making my toolchain non-portable:So that if on another system JDK11 is located under:
/usr/lib/jvm/java-11-oraclethe code above wouldn't work.Reproducer: https://gerrit-review.googlesource.com/c/gerrit/+/194040
The text was updated successfully, but these errors were encountered: