Kotlin-native: Repositories

[msink]

Current, work in progress, DSL for library dependencies is like this:

konanArtifacts {
    program('Curl') {
        dependencies {
            artifactCurl 'org.jetbrains.kotlin.native:libcurl:1.0'
        }
    }
}

I think instead of artifactSomething here should be 3 alternatives:

• dynamicLibrary
• staticLibrary
• library (meaning staticLibrary on some targets like mingw or zephyr, and dynamicLibrary elsewhere)

[olonho]

Could you please explicitly provide desired DSL and explanation, how DSL verbs shall behave.

[ilmat192]

Also let me briefly describe how these dependencies work at the moment. This dependencies block doesn't relate to a konanArtifact. It's just a Gradle's standard dependencies script block and the snippet you provided may look like this:

konanArtifacts {
    program('Curl')
}
dependencies {
    artifactCurl 'org.jetbrains.kotlin.native:libcurl:1.0'
}

The plugin creates a configuration with name artifactSomething for each konanArtifact declared. Then a user can use these configurations to specify dependencies for one or another artifact. Only klib dependencies are allowed here at the moment. So this 'org.jetbrains.kotlin.native:libcurl:1.0' is a klibrary published in a local maven repo.

[msink]

Well, I assume that somewhere is (will be) maven repo with set of .klib files, produced by K/N's cinterop tool for many popular C libraries, and by library dependency I mean dependency on that .klib.

As C libraries can be linked differently:

• dynamic
• static
• whole-archive

it should somewhat be expressed in DSL.
I do not know how should that dynamic/static flavors be packed - in single or in different .klib

Also in .klib should be some method to include files needed only in install task.
These files needed in runtime, and should be placed alongside with resulted program.

I personally do not have strong opinion how all this should be expressed in DSL.
But IMHO everything related to some artifact should be in single place, including dependencies.

[ilmat192]

I see, thank you for the clarification. You're right, we need to provide some convenient way for working with interop dependencies. But I think this feature should be additionally discussed and designed.