Skip to content

Latest commit

 

History

History
97 lines (75 loc) · 4.51 KB

2020-09-29-new-default-target-constraint.md

File metadata and controls

97 lines (75 loc) · 4.51 KB
created last updated status reviewers title authors discussion thread
2020-09-29
2020-10-19
Dropped
katre
Adding a constraint to default target platform
comius

Toolchain resolution already supports different languages in Bazel. Toolchains describe tools or libraries a specific language needs during build. Each toolchain can specify constraints for the target and execution platforms. For example a CC cross-compiler can run on execution platform with x86 cpu and produce code for target platform which might be arm cpu. Toolchain resolution takes care of selecting the right toolchain. For example in "target" configuration, target constraints have to match target platform and execution constraint have to match execution platform. Similarly in "exec" configuration the produced results are expected to work on execution platform, so both target and execution constraints of a toolchain need to match execution platform constraints.

The target and host platforms are currently automatically configured with constraints for cpu and operating system. Both platforms have identical constraints.

Java currently doesn't use toolchain resolution, however it provides two Java specific toolchains, namely java_runtime and java_toolchain. Toolchain java_runtime provides information about JDK or JRE (e.g. path to java) and about its system libraries. Rule java_toolchain defines mostly Bazel specific tools that are used for compilation, however the compilation is done by the internal compiler of JDK coming from java_runtime.

To build a Java target, where target and execution platform are the same, Java would already use two different JDKs: one from remote repository for compilation and a JDK installed on the machine to resolve symbols in system libraries and within runfiles and a stub used to execute the target.

Rationalia for those two requirements are:

  • Use JDK from remote repository for compilation in order to have hermetic compiles.
  • Use locally installed JDK in order to execute Java code without Bazel installed.

The problem

Because constraints are identical for target and host platforms, the toolchain resolution cannot come up with two different toolchains for the same type.

Proposal of the solution

I propose to add a new constraint to auto-configured target platform, making it different from the host platform. Thus making it possible to keep both Java requirements.

The new constraint_setting will be called toolchain_location with two values located_on_target_and_host and located_on_host_only, with the latter being the default value.

The constraint value located_on_target_and_host is added to the auto-generated target platform.

The semantics of the new constraint setting located_on_target_and_host on a target platform is: "I want to use target without Bazel". Setting the constraint on an execution platform, does not seem to have a use-case (or perhaps compile only with tools that are on target also).

Semantics of the new constraint on a toolchain is:

  • located_on_target_and_host - the target has this toolchain installed.
  • located_on_host - the target may not have this toolchain installed.

Example use on Java toolchain is that java_runtime pointing to local JDK, will have target constraints set to located_on_target_and_host.

The proposal does not have effect on toolchain resolution of already existing toolchains, because the new constraint setting is not set on them and the result of resolution stays the same.

Possible problem: The proposal has an effect on the users defining there own target platform(s) - if the constraint is not added, Java will be executed using JDK from remote repository. Usually this works fine, without producing errors or crashes.

Other options considered

  1. Other names for the constraint value were considered located_on_target, available_on_target, installed_on_target.

  2. Alternative is to add a constraint to autogenerated host platform. Considered name was hermetic/nonhermetic. The problem with that is that the users defining their own execution platform, need to add hermetic to it, otherwise local JDK could be used for compilation. This has high chance to produce undesired results or errors and crashes.

  3. Defining an additional toolchain type for Java. This seems to make code more complex and questionable when multiple different platforms a involved.

  4. Dropping one of the requirements for java and using just the JDK from remote repository.