What would be a good approach for K/N libraries th...

# kotlin-native

[vbsteven]

What would be a good approach for K/N libraries that "wrap" native libraries with possibly different versions where new minor upstream versions have additional functions/types and possibly deprecations? (for example GTK)

In the gtk-rs case in Rust land they handle it with Cargo features where an application developer can depend on the gtk4 crate which exposes the 4.0 API by default and features = [4_2] can be used in Cargo.toml to unlock newer API functions.

- One possible solution is to have different library versions for each upstream dependency version but that can get unwieldy quickly.
- Maybe something is possible with Kotlin annotations that conditionally enable additional methods based on properties in Gradle (equivalent to Cargo features).
- Another approach could be to not distribute generated bindings and instead wrap the bindings-generator (GIR-based) into a Gradle plugin that is configured with the desired library version in the gradle DSL and generates the bindings at build-time.

Has anyone already done something like this? Any thoughts?

[Big Chungus]

Sounds like a good fit for gradle build flavours variants and metadata

[Big Chungus]

https://blog.gradle.org/gradle-metadata-1.0

[Adam S]

Maybe something is possible with Kotlin annotations that conditionally enable additional methods based on properties in Gradle

would a custom opt-in annotation solve this?
https://kotlinlang.org/docs/opt-in-requirements.html#require-opt-in-for-api

[vbsteven]

Thanks, those are indeed the types of solutions I'm looking for. I'll give both the gradle metadata and opt-in annotations an experimental shot to see how they could work for this use case.

[Adam S]

are you asking about solving a problem when it comes to dependency resolution, so gtk consumers don’t get misaligned dependencies and build errors? Or just making sure that you can deprecate old or incubate new functionality?

[vbsteven]

I'm asking because I'm exploring GIR-based generation for gtk/gobject libraries for consumption in K/N and I'm trying to puzzle together all the infrastructure pieces required for a nice developer flow (generating bindings, gradle plugins for configuration and packaging etc). The end goal would be something similar to the gtk-rs project where an application developer can go "File -> New Project" and add some dependencies+gradle config to get an application project for building GTK applications in Kotlin Native.

[vbsteven]

There are still lots of open questions like: should the bindings be generated up front and published to maven central, or should the bindings be generated "just-in-time" by a plugin.

[vbsteven]

So it's mostly the "misaligned dependencies and build errors" thing. It is also why I'm looking at the full picture including application packaging.

[Adam S]

hmmm yes, that makes sense. So everything would ‘just work’ if you could package everything up into one package and publish it on Maven Central. And of course, you need a separate package per Windows/Linux/macOS type.

But you might also want to split up the package so it’s not too large, or because of license issues, or to provide flexibility. But then there’s an explosion because each split requires separate packages for Windows/Linux/macOS?

[vbsteven]

Indeed, those are some of the issues to be solved

[vbsteven]

but from early experiments done by myself, @Roberto Leinardi and some others it looks like something will be possible eventually.

[vbsteven]

A first approach using manually crafted bindings that I did in december/january already looks promising and is able to generate bindings for gtk/gobject/glib, that allows writing GTK application in KN that build and run on Linux, Windows and MacOS

[vbsteven]

(that initial experiment is here: https://github.com/vbsteven/gtk-kotlin-native )