Hi all. So i’m writing a pure kotlin library whi...

# multiplatform

[mattinger]

Hi all. So i’m writing a pure kotlin library which uses ktor as a dependency (ktor common and ktor mock). I don’t have any platform specific code. It seems odd that i need to publish a specific jvm and various iOS klibs when there is no platform specific code in there. Is there some way to configure the “multiplatform” plugin without having to explicitly call out the different platforms?

Is it enough to just call out “jvm” and publish the klibs and bring in the unqualified klib into the common source set of the downstream multiplatform project?

[jw]

No. You must compile to every target you support.

[mattinger]

That seems odd to me. I would have thought the klib that was published from the “common” sourceset would be everything i would need.

[jw]

There's all kinds of different reasons that doesn't work:

• Inline functions can reference platform specific things.
• Future targets may not support some API you use

[mattinger]

Thanks. @jw I was trying to peruse the ktor build files, and i’m curious how they have a single specific “darwin” client and publication. Those are very complex build files though and might take a bit to get through

[mattinger]

It just feels icky to do this:

jvm()
    iosArm64()
    iosX64()
    iosSimulatorArm64()

[mattinger]

when i have no code specific to any of these 😉

[jw]

But that's what you declare your common code supports

[jw]

With those targets you could use kotlinx.coroutines runBlocking. If you added JS, that would stop compiling.

[mattinger]

Fair enough. Still new to all of this, as are a lot of the folks i’m working with. Trying to figure it out as we go, and starting with code related to testing to reduce duplication of test code.

[mattinger]

I’m basically working on a clone of the okhttp mock interceptor, but for ktor’s MockEngine. Hopefully i can get some approvals to open source it.

[hfhbd]

Ktor looks at the src folder names and configures the targets. I would not recommend this. Instead, just use the target api. If you want to not repeat the targets, create gradle conventions/precompiled plugins.

[mbonnin]

There's a Youtrack about publishing pure Kotlin libraries but it's pretty much at the idea stage