Expose kotlinc's -Xfriend-paths to all jvm/android kt rules under the attribute 'assocates=' #465
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
cgruber
added
type: enhancement
…ates'. Associates lets a library associate it self to other libraries, making them part of the same module. This is constrained such that while multiple libraries may be associated, they must all shard the same module, and so cannot associate to anything that is part of a different module. These module relationships are in the bazel build graph, not the contents of the jars as such. This module membership is transitive (within the above-mentioned constraint), though strict-deps would stop that. Also, only kotlin targts can be associated.
cgruber
force-pushed
the
friends_and_associates
branch
2 times, most recently
from
29a6643 to
bc32af3
Compare
cgruber
changed the title
Bencodes
reviewed
Jan 27, 2021
restingbull
requested changes
Jan 28, 2021
chancila
reviewed
Jan 28, 2021
restingbull
approved these changes
Jan 29, 2021
restingbull
reviewed
Jan 29, 2021
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.
Associates lets a library associate it self to other libraries, making them part of the same module. This is constrained such that while multiple libraries may be associated, they must all shard the same module, and so cannot associate to anything that is part of a different module. These module relationships are in the bazel build graph, not the contents of the jars as such.
This module membership is transitive (within the above-mentioned constraint), though strict-deps would stop that. Also, only kotlin targets can be associated.
Per discussions across several media, the name "associates" was chosen over "friends" (despite the kotlinc flag being -Xfriend-paths) as that is the terminology used in the gradle kotlin plugin, which is kotlin's primary delivery vehicle, and to avoid confusion with the C++ friends concepts. The pre-existing "friends" attribute is preserved for backward compatibility with a warning. Future PR will add a flag to turn off that support, and then we'll delete it.
kt_jvm_import does not include this facility, but these can just set their module_name in common to participate.
Android should work, but because kt_android_* is a macro not a rule, the implicit target
//my/android/library:mytarget_ktshould be friended, since it has a KtJvmInfo. The//my/android/librarywill macro-resolve into an android_library. Until the android rules get the right kind of love, such that we can make a rule that has KtJvmInfo AND android-whatever providers, this simply is a known limitation we'll have to live with.Also, the prior implementation shoved the full transitive closure (all jars, kotlin or no) of the friend= into the
-Xfriends-pathsflag, which is awful. This PR does break that, in case people were relying on that by some oddity. The fix is to just add the targets directly.Fixes #211