Garrison Henkle
12/19/2024, 7:34 PMGarrison Henkle
12/19/2024, 7:34 PMjw
12/19/2024, 7:40 PMGarrison Henkle
12/19/2024, 9:30 PM.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!jw
12/20/2024, 3:45 AMI hadn’t ever seen afile without lots of fields in the “header” part.def
Is the create("quickjs") block... just defining those fields programmaticallyThat'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.jw
12/20/2024, 3:48 AMHow do you decide which header files need to go inI 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".?cinterops
jw
12/20/2024, 3:51 AMIsWe 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.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.cklib
jw
12/20/2024, 3:52 AMcinterop
DSL and doesn't even have a .def
file! https://github.com/JakeWharton/mosaic/blob/efa52eb8022242b727a5d2e5276ef1c56c623cc3/mosaic-terminal/build.gradle#L49-L54jw
12/20/2024, 4:00 AMGarrison Henkle
12/20/2024, 4:18 AMMichael Paus
12/20/2024, 8:39 AMkpgalligan
12/20/2024, 9:57 PMkpgalligan
12/20/2024, 10:02 PMkpgalligan
12/20/2024, 10:05 PMkpgalligan
12/20/2024, 10:34 PMGarrison Henkle
12/20/2024, 10:46 PMkpgalligan
12/20/2024, 11:43 PMwrite my own gradle task with the compilation and bundling steps to get more familiar with the whole processFor 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.