[wip] dep analysis for strict deps and unused deps #40
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hsyed
changed the title
|
@iirina I'm wondering if you could give this POC a review or suggest someone else. It would be useful if I could reuse any bits in Bazel core -- I am essentially rewriting the java builder with a Kotlin compile phase. |
…us for the user what to do
…asspath still used
hsyed
force-pushed
the
dependency_analysis
branch
from
8614db6
to
65e439c
Compare
hsyed
commented
May 24, 2018
| @@ -111,6 +119,11 @@ def define_kt_toolchain(name, language_version=None, api_version=None, jvm_targe | |||
| api_version = api_version, | |||
| jvm_target = jvm_target, | |||
| coroutines = coroutines, | |||
| jvm_strict_deps = select({ | |||
There was a problem hiding this comment.
@brendandouglas FYI this is how I am currently going to relay the strict dep flag to the builder. Is this the right place for it ? My initial thoughts were to go through a common hidden attribute on the rules but bazelbuild/bazel#287 prevents this. I can make it hidden here ?
p.s., This branch is quite chaotic atm so don't bother reading any of the other code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So this PR has a POC of strict dep checking working. The sequence of actions run within the builder is as follows:
Deps.Dependencies) against the--direct_dependenciesand--indirect_dependenciespassed via the command line.buildozeroutput and delete the generated jar.The dependency analysis / dependency selection is not in line with how the native rules currently do It bazelbuild/bazel#4584. The analysis is attempting to select deps further away from a jars
File.owner-- at least one hop but at the moment it could be much closer to the target. So for example a//third_party:guicelabel could be chosen for bothjavax-injectandguice. Perhaps the heuristic should prefer in-project labels exporting only one jar if available.A compiler plugin for Kotlin makes more sense so that we get more error context -- one short term work around is to run a compile phase after detecting indirect dependency usage with a restricted classpath and concatenate those errors with the buildozer suggestions. This doesn't cover the mixed mode scenario, currently java code is compiled by javac -- and writing a compiler plugin for javac makes no sense. Could the JavaBuilder be leveraged here without going back out to skylark ?