vbsteven
02/28/2023, 8:13 AMgtk-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
02/28/2023, 9:16 AMAdam S
02/28/2023, 9:20 AMMaybe something is possible with Kotlin annotations that conditionally enable additional methods based on properties in Gradlewould a custom opt-in annotation solve this? https://kotlinlang.org/docs/opt-in-requirements.html#require-opt-in-for-api
vbsteven
02/28/2023, 9:26 AMAdam S
02/28/2023, 9:30 AMvbsteven
02/28/2023, 9:38 AMgtk-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.Adam S
02/28/2023, 9:50 AMvbsteven
02/28/2023, 9:50 AM