Publishing a pure Kotlin Multiplatform library seems quite challenging, or perhaps I haven't found t...

# multiplatform

[zsqw123]

Publishing a pure Kotlin Multiplatform library seems quite challenging, or perhaps I haven't found the right approach.
In my experience, I have to specify each supported platform in my build script. However, when writing Multiplatform libraries, I primarily use Kotlin Multiplatform to "share common code". I rarely write platform-specific code, partly because Kotlin's cinterop lacks documentation and source code examples, making platform-specific coding less appealing. Additionally, I need to set up various environments for my target platforms, which often requires a macOS machine or a well-configured GitHub macOS Action. This setup can be cumbersome, and I end up publishing numerous unnecessary Maven artifacts for each platform.

Does Kotlin 2.0 offer any optimizations for publishing only commonMetadata sourceSet? My goal is to publish a straightforward Multiplatform library that support all platforms and depends solely on the Kotlin std-lib. (Rust did such publishing processes very well for me.)

[ephemient]

no. "common" is the intersection of the current targets, and can't take limitations of future targets into account

[ephemient]

there is some design work being done to consider simplifying publication, https://youtrack.jetbrains.com/issue/KT-68323

[ephemient]

but "platform-agnostic pure-kotlin libraries" are unlikely to exist anytime soon https://youtrack.jetbrains.com/issue/KT-52666

[ephemient]

being able to produce macos native klibs from other platforms should arrive first, https://youtrack.jetbrains.com/issue/KT-66944

[zsqw123]

Thank you for your answer, it's very detailed. Now I know that the klib team seems have such idea. And currently, it seems that we can only use complicated processes to publish our artifacts.gradle intensifies

[khalid64927]

I use this plugin ( I'm the author) https://github.com/khalid64927/khalid-gradle-plugin

[hfhbd]

If you are using GitHub Actions and your repository is public available, the laziest way is using the macOS runners for publishing all targets.

[CLOVIS]

If you use GitLab, I have most of this setup in CI, if that helps

[CLOVIS]

Rust did such publishing processes very well for me.

This is because Rust libraries are always built from source, so your users are rebuilding the library on their machine. In the Kotlin world, we build binaries that users import into their projects, so they can't import binaries you haven't built.