Are there resources / documentation pages on how t...
# multiplatform
g
Are there resources / documentation pages on how to bundle native libraries with KMP apps and libraries? I’ve been using Zipline as an example, but there’s still a few things I don’t understand about about the whole process.
I’m going to watch this later, but I haven’t been able to find too much outside of this: https://vimeo.com/371460823
j
Happy to answer questions about Zipline's use of cklib to accomplish this here or in #C5HT9AL7Q. And we can rope in Kevin, too.
g
Thanks, that would be awesome! I think your commit from 30 minutes ago actually answered all my questions about the JVM side 😅 . I did have three questions about the native side, though: 1. I hadn’t ever seen a
.def
file without lots of fields in the “header” part above the
---
. Is the
create("quickjs")
block in `zipline/zipline/build.gradle.kts`’s cinterop just defining those fields programmatically, or is that something the
cklib
plugin handles? It looks like some of the fields I expect to be in the
.def
are in the
create("quickjs")
block of the
cklib
plugin config instead, but I wasn’t sure if that was separate configuration just for the plugin. 2. How do you decide which header files need to go in
cinterops
? I see 4 different files declared in the gradle, but there are several other ones in the
/native
directory. Are the other ones only called from C making the Kotlin bindings unnecessary? 3. (This one is probably better for someone at Touchlab) Is
cklib
going to be maintained for the foreseeable future? The readme acts like it’s not going to be generally supported outside of Touchlab’s clients. Unrelated, but the new Zig build script in that commit is super cool! I’d heard that Zig could compile C, but I wouldn’t have ever thought to use the Zig compiler to compile a pure C project!
j
I hadn’t ever seen a
.def
file without lots of fields in the “header” part
Is the create("quickjs") block... just defining those fields programmatically
That's right. The DSL is newer, the
.def
file is original. You don't even need a
.def
file anymore unless you have bits to write in C in the body.
How do you decide which header files need to go in
cinterops
?
I only put in headers which have APIs that I want to call from Kotlin. I honestly can't remember if you automatically get stubs generated from included header files or not–you probably do. But it's nice to be explicit about "I'm using these APIs".
Is
cklib
going to be maintained for the foreseeable future? The readme acts like it’s not going to be generally supported outside of Touchlab’s clients.
We are relying on it, so we will pay them to fix it if it breaks so long as we continue to rely on it. I don't know if they have other paying clients who use it or not. You can use it, but I wouldn't expect them to help you much or add new features if you run into problems.
👍 1
If you want to look at another project using it there's one here: https://github.com/JakeWharton/mosaic/tree/trunk/mosaic-terminal. Also note that this only uses the
cinterop
DSL and doesn't even have a
.def
file! https://github.com/JakeWharton/mosaic/blob/efa52eb8022242b727a5d2e5276ef1c56c623cc3/mosaic-terminal/build.gradle#L49-L54
Slack removed my ability to delete unfurls. Whhhyyyyy. (Support said widespread issue today, hard reload will restore "x" to remove)
kodee sad 1
g
This is super helpful! Thank you so much!
m
The video mentioned above can only be watched if you have a Vimeo account because it wasn’t rated yet. Maybe someone can change that.
k
On a phone, so minimal details. Typing is slower.
Cklib isn't complex itself. The "we don't support this" is mostly because the vast majority of questions are related to native builds and linking, not cklib. Those are complex topics that many kmp devs don't understand, as they're usually android/jvm devs without much native experience. If there's an issue that can be clearly isolated to cklib, happy to chat :)
gratitude thank you 1
That talk is old. This is more current. https://www.droidcon.com/2022/06/28/sdk-design-and-publishing-for-kotlin-multiplatform-mobile/ . Droidcon listed the title wrong on the site and in the video. I should maybe redo it on YouTube...
Tl;dw cinterop defines the kotlin, but doesn't do anything for the binary (except things inline in .def). cklib builds c/objc with platform flags and pushes that into klibs.
g
I’ll check out the video later, thanks for the link! I was looking at cklib’s source a bit last night, and I honestly might write my own gradle task with the compilation and bundling steps to get more familiar with the whole process. My knowledge of how jars are put together is already a bit lacking, so I’ll probably do a deep dive into jars and klibs over the weekend. Thanks for the info!
k
write my own gradle task with the compilation and bundling steps to get more familiar with the whole process
For some more cklib info, it loads a jar that's generally used by the Kotlin compiler to generate flags specific to C and ObjC builds per-platform. On the longer term plan was to simply extract them and put them into cklib directly. The idea was to not have to periodically check the Kotlin code for changes and/or new architectures. However, that stuff doesn't change so much, so the way it works is arguably more complex than necessary. But, the urgency is generally low until the Kotlin compiler changes something sufficiently enough to break cklib. Stepping back a bit, KMP really could use a better way to build native code, as well as better linking mechanisms for 3rd-party libraries. On iOS, that's currently CocoaPods as linkOnly, but that's rather confusing to explain. There's also no formal SPM support. But, I digress.
gratitude thank you 1