I realized that <#C19FD9681|gradle> might not be the right channel for this question, because it’s a...

# build-tools

[ralf]

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

[serebit]

You're right, that does sound gross

[jw]

👍 I would like this as well. Does using the freeCompilerArgs not work?

[danny]

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

[danny]

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

[danny]

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

[danny]

It lets tests get at the main sources

[ralf]

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

[jw]

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

[ralf]

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

[orangy]

@h0tk3y any ideas?

[ralf]

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

[ralf]

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

[h0tk3y]

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

[ralf]

@h0tk3y Can you tell me if friend dependencies work transitively? Let’s say I have A -> B -> 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

[ralf]

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

[h0tk3y]

@ralf 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.

[h0tk3y]

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.

[ralf]

Thanks, that’s helpful!