A modern programming language that makes developers happier.

kotlinlang

I realized that <#C19FD9681|gradle> might not be the right channel for this question, because it’s about the Kotlin DSL. Is there a way to do this?

:+1: I would like this as well. Does using the freeCompilerArgs not work?

Problem with the free-args is IntelliJ isn't going to know about the relationship when it interrogates the model for the project

Looks like `AbstractKotlinCompile` has `friendTaskName` and the model knows how to tell IntelliJ about them, but they're internal fields

Looks like this guy is doing the mapping - <https://github.com/JetBrains/kotlin/blob/914f7c8719d0a9ca60d0560f9d263314079109ca/libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/plugin/TaskToFriendTaskMapper.kt>

It sounds gross, but is actually useful because Gradle doesn’t provide the granularity that some projects need.

I don't even think it's gross. The java module system supports this as well. The upstream project declares which downstream projects can see its version of 'internal' things

Looking through the code of the plugin, it doesn’t seem like it’s possible with proper IDE integration. The code that <@U0B9S0W2D> linked only looks at tasks and I want to refer to multiple modules (or their tasks).

There has been an issue filed already: <https://youtrack.jetbrains.com/issue/KT-20760>

This will be part of 1.3.60. I’m excited!

Note that the IDE won't properly support this in the first 1.3.60 EAP (where it will only work in Gradle). Please follow <https://youtrack.jetbrains.com/issue/KT-34102>

<@U0B9PKJ7K> Can you tell me if friend dependencies work transitively? Let’s say I have `A -&gt; B -&gt; C`, C is a friend of B, B is a friend of A. Is C a friend of A, can A see internal code from C? There is a discussion going on how this should be implemented for Bazel <https://github.com/bazelbuild/rules_kotlin/issues/211>

See also here in the Slack channel: <https://kotlinlang.slack.com/archives/C0B8PUJGZ/p1572375299002700>

<@U3M0FHPC0> With the associated compilations available in 1.3.60, yes, the internals visibility works transitively. As compilations can be associated with each other only within a single Gradle project, limiting the internals visibility to just the direct associations wouldn't be really useful (at some point, we even considered allowing access to the internals between _any_ compilations within one Gradle project, not just those connected with the `associateWith` relation). Let me take a closer look at the proposal.

<https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/tasks/Tasks.kt#L236> – here, you can see that the `friendPaths` passed to the compiler are based on the transitive closure of `associateWith`.