https://pantsbuild.org/ logo
Join Slack
Powered by
(coming into this with basically no context, but B...
# development
r
(coming into this with basically no context, but Bazel does have a distinction between “host”, “execution” and “target” platform: host is where bazel is running, execution is where build actions execute, and target is where the build output is intended to run. this captures the situation of running bazel on a mac, executing remotely on linux machines, building a windows binary, as one example)
👌 1
a
the reason why this is a lot of complexity for pants in my eyes is that: (1) we don't support windows (2) a mac cluster to remotely execute things against is extremely expensive which leaves linux as the single remote execution platform, and cross-compiling to osx is very difficult, to say the least. to me, introducing these concepts in pants would only be useful to support cross-compilation, and i personally do not want to be on the hook to support that, and i don't see introducing cross-compilation as being enough of a benefit for any use case to justify the continuing cost of supporting it. this is why i'm a bit iffy about following bazel's lead in this particular case.
👍 1
h
Agreed that we will only ever remote in Linux. Can't comment about cross-compilation. I don't understand that enough. (Thanks Clint for the input!!)
h
I don't agree that we will only ever remote in Linux, FWIW
Building on a MacOS cluster is probably going to be a thing
Also we will likely want to support windows "some day"...
But yes, not sure we will ever cross-compile
a
i agree on all of that, as long as the conclusion is not supporting cross-compilation, because implementing the toolchain for that is possibly a lot of work unless someone else has it figured out
a
I’ve put this in the doc, but: While we may not want to support cross-compilation any time soon, we do want to support a limited form of it, which is that the output of a JVM compile is platform-independent, but we want to be able to run actions on both an OSX laptop and a Linux remote machine to generate platform-independent output. That’s why we need to properly model platform-specific inputs, and platform-independent outputs, which the native backend doesn’t currently do in a granular way.
a
Copy code
@union
class JvmCompileExecution: pass

# UnionRule(JvmCompileExecution, LocalJvmCompileExecution)
# UnionRule(JvmCompileExecution, RemoteJvmCompileExecution)

@rule(SpeculativeJvmCompileOutput, [JvmCompileRequest, RemotingOptionsSubsystem])
def speculative_jvm_compile(jvm_compile_request, remoting_options_subsystem):
  local_image = yield Get(ZincNativeImage, NativeImageRequest(jvm_compile_request.zinc_version, Platform.current)
  remote_image = yield Get(ZincNativeImage, NativeImageRequest(jvm_compile_request.zinc_version, remoting_options_subsystem.remote_platform)
  local_req = LocalJvmCompileExecution(local_image, jvm_compile_request)
  remote_req = RemoteJvmCompileExecution(remote_image, jvm_compile_request)
  local_result, remote_result = yield [Get(JvmCompileOutput, JvmCompileExecution, exe_req) for exe_req in [local_req, remote_req]]
  yield SpeculativeJvmCompileOutput(local_result=local_result, remote_result=remote_result)
Open in Slack
PreviousNext
Powered by