Is it possible to link one def file to another? F...
# kotlin-native
c
Is it possible to link one def file to another? For example, In my gtk kotlin library I want to separate the different headers of gtk into subprojects to lower build times while developing. If I were to have a def for each, I would have repeated bindings generated. IE GError then another GError then another GError. The idea is that, by linking one def as a requirement for another, It would just build on top of the previous def and not need to regenerate code TLDR; Dependencies of def for a def
b
Not exactly, but you can filterHeaders in def files to avoid duplicate bindings
c
Fun fact, It is possible to build on top of other cinterop bindings. By putting together the correct filters, you can avoid duplicate bindings while also building on top of them. Made a ton of things easier in my library now 😄
👍 1
b
Btw are you by chance including cinterops as static library? I'm struggling with that recently...
c
I am using it as a sharedlib, Are you using pkg-config and such to use the correct flags?
b
I am, but I'm still getting undefined symbols from glibc (dependency of my c lib I'm linking)
It's literally the post above yours 😀
I'm linking libmongoc-static-1.0 on ubuntu
c
I apologize, I am as clueless as you are. Wish we had better documentation / tools to do this
b
Yeah, the sole example of this is using overly simple c lib, unfortunately. Also def file example for that is incomplete (missing linker and compiler opts)
n
Going with modular libraries is another way to significantly decrease the build time, which works in many cases.
With a Kotlin Native program linking takes up most of the build time. Currently the build time with linking in Kotlin Native is painfully slow 🐌 . There are no immediate signs that the Kotlin team is working on speeding up the linking process (nothing on linking in the current Kotlin Roadmap).
b
How did you solve c dependencies issue? If you have clib A that depends on clib B and you try to split them into a.def and b.def under different packages all the functions generated by clib A will reject clib B types (due to different package) when using them from kotlin.