https://kotlinlang.org logo
Title
m

mbonnin

08/04/2022, 12:47 PM
Hi 👋 . Looks like compiling a native lib with 1.7 requires consuming it with 1.7 (or we get a
Incompatible abi version
) 1. is that true? 2. could we allow consumption with 1.6 by adding
languageVersion = "1.6"
when compiling? Looks like this works for JVM but not for native?
j

Jeff Lockhart

08/04/2022, 2:03 PM
I believe this is what
kotlin.mpp.enableCompatibilityMetadataVariant=true
takes care of. See docs here.
e

ephemient

08/04/2022, 2:05 PM
I thought that's for hmpp which changed defaults with 1.6.20
m

mbonnin

08/04/2022, 2:05 PM
Yea, I was expecting
enableCompatibilityMetadataVariant
to be more about the metadata than the abi but I'll investigate
e

ephemient

08/04/2022, 2:06 PM
https://kotlinlang.org/docs/components-stability.html still has native klibs as "alpha stability" so I don't think there's a promise of cross-version compatibility
m

mbonnin

08/04/2022, 2:07 PM
That sounds reasonable.
r

russhwolf

08/04/2022, 2:24 PM
There's not a guarantee of backward compatibility for Kotlin/Native but it has been provided experimentally since 1.4. Not sure how that plays into
languageVersion
though. https://youtrack.jetbrains.com/issue/KT-42293
m

mbonnin

08/04/2022, 2:25 PM
Exactly, the question is whether a newer compiler can generate a binary that uses the older format. JVM can do it with
languageVersion
but looks like native can't
It'd be a useful tool for lib authors to leverage newer tooling (use KGP 1.7 for their own build) but still ship compatible binaries
r

russhwolf

08/04/2022, 2:27 PM
It might be worth asking in that ticket to clarify if that's expected to work or not (and whether it's on the roadmap otherwise)
m

mbonnin

08/04/2022, 2:27 PM
It's not too much of an issue right now as K/N users usually upgrade quite fast but as the ecosystem matures it could be handy
I'll ask on that ticket
r

russhwolf

08/04/2022, 2:28 PM
yeah it's not one I think about as much as I probably should, but it'd be nice to get to the point where we have well-defined best practices around that sort of compatibility.
j

Jeff Lockhart

08/04/2022, 3:25 PM
I guess the question would be whether backwards compatibility exists in language versions or would need to be supported first. That might be the main hurdle while things are changing quickly in Kotlin/Native, probably more difficult to support than not.