If I want to publish the Kotlin/Native library to ...

# kotlin-native

[Sujit]

If I want to publish the Kotlin/Native library to be used by another project (kotlin multiplatform project for example), what is the best way to publish it? The way i understand it, kotlin native would mean many different hardward architecture. So, for the dependency manager via something with implementation() on gradle, how does it resolve the architecture to download? Currently I have a publication on maven, but I'm also uploading the .klib. Is there a way to avoid that so that I won't have to upload separate publications for all the hardwares I want to support? I'm sorry this is like a long multi-question question, but I've been wrecking my brain trying to make this work... Help please.

[kpgalligan]

This is handled with gradle metadata. A single “library” will publish several actual artifacts, but the target is ultimately chosen by gradle by way of metadata attributes.

[kpgalligan]

Those are all published artifacts

[Sujit]

Oh, interesting. So, now, when trying to use in the dependencies block, you could just do squilter, for any native components, and it would know which one to get?

[kpgalligan]

Your common dependency would still be implementation 'co.touchlab:sqliter:0.6.4' and gradle would sort it out (assuming you were on a sufficiently recent version of gradle)

[kpgalligan]

Yes

[Sujit]

So, if common dependency would be implementation 'co.touchlab:sqliter:0.6.4', and then what would be the native dependency? implementation 'co.touchlab:sqliter:0.6.4' too?

[kpgalligan]

Yes, could be. sqliter is a bad example as it’s really just for native, even though I publish a jvm artifact.

[Sujit]

Ahh, I see. That makes so much sense now

[kpgalligan]

You could put that dependency in common or in the native deps and it would find it

[Sujit]

That's pretty great. Yeah, do use 5.6.2 gradle, so I should be good on that

[Sujit]

So, in theory, it is possible to have implementation 'co.touchlab:sqliter:0.6.4' for all the platforms including the jvm/android one?

[kpgalligan]

Yeah, it’s a lot more fun now that the metadata is 1.0. Pre 1.0, each library needed to be republished for different ranges of gradle

[Sujit]

Wow. That's really great!

[kpgalligan]

Yes. Stately is a better example. There’s jvm and native, and you just reference the common dependency.

[kpgalligan]

Another example: https://github.com/russhwolf/multiplatform-settings

[kpgalligan]

For “shared prefs”

[kpgalligan]

One of the talks I’ve overcomitted myself to is libraries …

[Sujit]

That's pretty cool. So, in our readme, I guess we have to say which particular native arch do we support?

[Sujit]

That's fantastic @kpgalligan. I'm really looking forward to those talks

[kpgalligan]

Yeah. That is a tricky thing. I originally had no linux or windows, but it turns out people actually use them…

[kpgalligan]

Haven’t published a wasm or native android lib yet, though

[Sujit]

😄

[Sujit]

Cool. I think its all about the principle that I was really missing here. That's what we need for people trying to make this jump I think

[kpgalligan]

I’ve spent the whole day working on concurrency talk. As mentioned, that’s I think the really big one. For libraries, understanding what gradle does with them is super important. Can’t use jitpack, btw

[Sujit]

Yeah, that was my first attempt. Jitpack. We have used jitpack here so far. Now, looks like we are moving out

[kpgalligan]

There is (I think) experimental support for building windows from a mac machine, but not sure where that is. I currently build windows from parallels. Assume windows isn’t a big priority, but depending on what you’re building, it may get requested

[Sujit]

That's interesting. Yeah, at the moment, we are not very windows friendly. But, definitely something we might in the future