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?

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

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

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.

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?

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.

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?

Indeed, those are some of the issues to be solved