Can anyone explain why cinterop tasks depend on th...

# kotlin-native

[natario1]

Can anyone explain why cinterop tasks depend on the project dependencies? 😕 what's the use case here? https://github.com/JetBrains/kotlin/blob/a766369e7283d7b89a5ca2960460dc20365f919a/libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/targets/native/KotlinNativeTargetConfigurator.kt#L389-L405

My project X depends on project(":Y") and on some cinterop libraries. Because of how cinterop tasks are configured by the Kotlin plugin, anytime Y changes, all the interops are executed again, slowing down the build.

[Kris Wong]

that does seem odd

[Kris Wong]

i hadn't noticed. but i only have 1 smallish interop on 1 project.

[natario1]

Here, they're the most static thing in the whole project, yet they're executed on most builds, taking up to 20 seconds. I'm wondering if this config makes sense for some use cases or if I should open a bug

[ilya.matveev]

Hi! The main idea behind this dependency is the following.

Consider two dependent native libraries A -> B. We create a Kotlin wrapper for the B library and publish it (name this wrapper B-kt). Now we want to interop the A library and use it together with B-kt in an app. In this case cinterop bindings produced for A and B should be compatible. To achieve that, we pass a cinterop klib produced for B and published with B-kt to the cinterop tool, when we produce bindings for A.

In this case, if the cinterop tool find some `B`'s symbol in `A`'s API, it will not generate a new binding for it. Instead, it will use the already generated binding, so Kotlin APIs of A and B will be compatible.

But I agree that the Gradle plugin can be more smart here and don't consider non-cinterop klibs as inputs for cinterop tasks.

Add a link to your issue to this thread, just for the record: https://youtrack.jetbrains.com/issue/KT-42056

[natario1]

Thanks for explaining Ilya!