Is there some option to expose module A cinterops to be visible to module B that consumes module A?

# kotlin-native

[Big Chungus]

Is there some option to expose module A cinterops to be visible to module B that consumes module A?

[Adam S]

using Gradle? I thought that happens automatically with a implementation(project(":module-a")), but maybe IntelliJ takes a while to work it out.

[Big Chungus]

Wasn't my experience so far. Module B doesn't compile

[Adam S]

what’s the error?

[Big Chungus]

Unresolved type

[Adam S]

I’m working on a KN project right now that has a .def file that generates cinterop code in one subproject, and another subproject that adds a dependency on it and I’m writing more user-friendly interop code.

[Adam S]

in the cinterop project I have this config. Do you have binaries.staticLib()?

kotlin {
  targets.withType<KotlinNativeTarget>().configureEach {
    compilations.getByName("main") {
      cinterops {
        val extLib by creating {
          defFileProperty.set(file("$projectDir/ext-lib.def"))
        }
      }
    }
    binaries { binaries.staticLib() }
  }
}

[Big Chungus]

Is your module b referencing A cinterop from commonMain?

[Adam S]

no, not commonMain. I’ve set up a custom nativeMain source set

[Big Chungus]

I have all three desktop targets only and write my native code in commonMain

[Big Chungus]

NativeMain didn't work at all for me

[Adam S]

I’ve changed the consuming project to use commonMain, and that also works

[Adam S]

have you disabled the hierarchical source sets in gradle.properties, maybe?

[Adam S]

what’s the full error? Maybe a platform type is missing on one of the targets?

[Big Chungus]

It's the same error as if I were to reference org.totally.non.existing.Type

[Big Chungus]

I can see the cinterop in commonMain of A

[Adam S]

oh, I also have a workaround in the consuming project. For some reason cinterop didn’t commonize a typealias

https://youtrack.jetbrains.com/issue/KT-56102

[Big Chungus]

Aha! Must be it!

[Big Chungus]

Thanks

[Big Chungus]

What's your workaround?

[Adam S]

oh, just to set up the actual/expects manually

[Adam S]

the problem was was a function that was generated in all targets, but not commonized

package cinterop.internal

public external fun SetTraceLogCallback(...)

so in commonMain I created an expect

expect fun setTraceLogCallbackInternal(...)

and then in linuxX64Main, macosX64Main, mingwX64Main I created actual functions that deferred to the generated functions for each target

actual fun setTraceLogCallbackInternal(...) {
  cinterop.internal.SetTraceLogCallback(...)
}

[vbsteven]

Have you tried with api instead of implementation?

[Big Chungus]

I HAVEN'T tried implementation 😀

[vbsteven]

with cinterop I don't see much difference between api and implementation. If I do something like
``````

[vbsteven]

dependencies {
  implementation(project(":my-cinterop-bindings"))
  api(project(":another-cinterop-bindings"))
}

Both approaches seem to make all the cinterop stub functions and types available

[vbsteven]

ah but I don't use commonMain for anything. It's all nativeMain

[Big Chungus]

Hmm, at least I now know that cinterops should be visible to consumers. I'll try creating minimal repro to see when things start breaking for me.

[Big Chungus]

commonMain is supposed to be better supported than nativeMain for commonisation (since nativeMain support came much later)

[Adam S]

oh, I’ve manually set up nativeMain. I didn’t realise there was a new default in 1.8.20.