Remove ijar from the bazel binary. #7665
Conversation
|
@lberki ijar is also used by the android rules. I wouldn't go forward with removing ijar from the bazel binary until there is a clear story for the Android tools. The difference in binary size (with and without ijar) is ~ 0.1M so there is not much gained. |
src/main/java/com/google/devtools/build/lib/bazel/rules/java/jdk.WORKSPACE
Outdated
Show resolved
Hide resolved
|
Like the other Java tools, this looks like a transparent change to the Android rules, since ijar will now be downloaded at build time instead. Is that accurate? |
c1ba3bc to
da33f09
Compare
|
@lberki The PR is now ready for review 🎆 I added more details in the first PR comment. |
|
@jin yes, that's accurate. I was worried because there are some genrules in the android tools that use ijar directly ( |
| def _get_args(target, attr, **kwargs): | ||
| workspace_target_dict = { | ||
| "//src/conditions:linux_x86_64": ["@remote_java_tools_linux//" + target], | ||
| "//src/conditions:linux_aarch64": ["@remote_java_tools_linux//" + target], |
There was a problem hiding this comment.
We don't have a separate ijar build for Aarch64, do we? But if not, how does this work? An ijar binary built for x86_64 surely won't run there...
There was a problem hiding this comment.
We don't have a separate ijar build for aarch64. I assumed it might work with the same binary, but if it doesn't I am open to suggestions...
Previously when ijar was embedded into bazel, it used either the cc_binary target (in remote execution) or the prebuilt embedded binary for all other cases... If someone was using the linux bazel release on linux aarch64 then ijar probably didn't work for them... In this case I assume they compile bazel themselves? If so, they have to do the same with the Java tools... which makes things more complicated at this point.
There was a problem hiding this comment.
As discussed: build a source archive and direct //conditions:default to that?
There was a problem hiding this comment.
Actually I realized we can re-use any of the already existing archives (I choose the linux one). The BUILD file in the remote repository returns the prebuilt ijar binary for the 3 known platforms and the cc_binary target for all the others (+ remote execution). All the other targets are deploy jars and the platform doesn't matter in their case.
|
@lberki Thanks! I moved the BUILD files embedded into the bazel binary from |
|
...and that also :) |
3cff3fa to
75f1744
Compare
|
|
75f1744 to
8d02e74
Compare
Partial commit for third_party/*, see #7665. Signed-off-by: iirina <elenairina@google.com>
|
|
Bazel now doesn't embed ijar anymore and uses ijar embeded in the Java tools remote repository.
Bazel embedded both ijar's source code (required by remote execution) and platform specific pre-built binaries. This change adds platform specific remote Java tools repository that include the corresponding pre-built ijar binary (for Windows, Darwin and Linux), alongside ijar's source code.
This change introduces a collection of macros that wrap the native rules
filegroupandjava_importand select a given target from the external java tools repository based on the current platform.Progress on #6316.