Per-JvmTarget compile settings (-source, -target, args) to support multiple jvm levels.

Review Request #2494 - Created July 17, 2015 and submitted

Information
Garrett Malmquist
pants
gmalmquist/mixed-jvm-levels
1826
f8022a0...
Reviewers
pants-reviews
jsirois, nhoward_tw, patricklaw, zundel

Added target_level, source_level, and compile_args to jvm_binary.

The global compile strategy partitions targets by their JvmPlatformStrategies
before compiling them, but short-circuits to just compile them all together
if all the targets have the same platform.

The partitioning also respects target dependencies, so two dependent
targets with the same compile settings may be compiled in different
chunks if they are separated by an intermediate dependency with
different settings. An example and test of this behavior can be
found in test_java_compile_settings_partitioning#test_chunks_respect_dependencies.

Added lots of integration tests and unit tests under: tests/python/pants_test/backend/jvm/tasks/jvm_compile/java/test_java_compile_settings_integration.py and tests/python/pants_test/backend/jvm/tasks/jvm_compile/java/test_java_compile_settings_partitioning.py.

CI went green here: https://travis-ci.org/pantsbuild/pants/builds/71341662
And here: https://travis-ci.org/pantsbuild/pants/builds/71817136
And here: https://travis-ci.org/pantsbuild/pants/builds/72320050
And here: https://travis-ci.org/pantsbuild/pants/builds/72346982
And here: https://travis-ci.org/pantsbuild/pants/builds/72854625
And here: https://travis-ci.org/pantsbuild/pants/builds/72875285
And here: https://travis-ci.org/pantsbuild/pants/builds/72923807
And here: https://travis-ci.org/pantsbuild/pants/builds/73068044

Issues

  • 0
  • 17
  • 1
  • 18
Description From Last Updated
Eric Ayers
Garrett Malmquist
Eric Ayers
Stu Hood
Nick Howard (Twitter)
Garrett Malmquist
Garrett Malmquist
Garrett Malmquist
Garrett Malmquist
Eric Ayers
Garrett Malmquist
Nick Howard (Twitter)
Eric Ayers
Garrett Malmquist
Stu Hood
Garrett Malmquist
Eric Ayers
Garrett Malmquist
Garrett Malmquist
Stu Hood
Garrett Malmquist
Garrett Malmquist
Stu Hood
Garrett Malmquist
Eric Ayers
Garrett Malmquist
Review request changed

Status: Closed (submitted)

Change Summary:

In commit bde9d56e80c01e4a2ae4424738b8879230b00c9e

Benjy Weinberger

   

Why do these both need to be in the fprint? I think the subscope values are the only ones you need. The global instance's values shouldn't matter?

(Just noticed this code while working on a related change in that file...)

  1. If I recall, I needed that behavior for JvmPlatform because very many tasks uses it (all the subclasses of JvmCompile), but we use the global jvm-platform option space to control all of them. So their behavior is dependent on the global options, not just the subscope'd options.

    You can try commenting out that line and running ./pants test tests/python/pants_test/backend/jvm/tasks/jvm_compile/java::; I'm pretty sure it'd break something.

  2. Well, if a task registers a dep on the task-specific instance it's not supposed to read the global instance. But you're right - this is necessary because for non-recursive options, if you read the value from the task-specific instance that read gets delegated to the global instance, but that option isn't registered directly on the task-specific instance (it would be if it were recursive), so the fprinting code never iterates over it on that task-specific instance.

    I may change this as part of a related change to be a bit more rigorous - i.e., it recurses upwards to the global scope, rather than just singling out these two cases. Because hypothetically you can read any value from any enclosing scope.

    Thanks for clarifying!

Loading...