https://kotlinlang.org logo
#gradle
Title
# gradle
m

mike.holler

02/02/2023, 3:47 PM
Probably a stupid question. Is it possible to have different gradle sub-projects with different Kotlin version targets? I'd like A to target Kotlin 1.8 and B to target 1.7.20. A depends on B. Assume A is a server and B is a client SDK. Would I have to use composite builds?
v

Vampire

02/02/2023, 3:56 PM
I think you can use the 1.8 Gradle plugin and configure the language level for B using configuration
m

mike.holler

02/02/2023, 3:56 PM
Can you elaborate on "configure the language level"?
Note that this is a multiplatform project, so I'm not talking about JVM version.
a

Adam S

02/02/2023, 3:58 PM
why do you want to use different Kotlin versions?
v

Vampire

02/02/2023, 3:58 PM
There is
apiVersion
add
languageVersion
to configure
m

mike.holler

02/02/2023, 3:58 PM
SDK needs to support clients using lower Kotlin versions than our server.
a

Adam S

02/02/2023, 3:58 PM
yeah, that’s what
apiVersion
is for 👍
m

mike.holler

02/02/2023, 3:59 PM
Attributes common to JVM and JS
Not native?
c

CLOVIS

02/02/2023, 3:59 PM
Yes, you can do this with composite builds which all import different versions of the Kotlin plugin, but that's probably overkill. The other solutions with
apiVersion
are most likely what you want
v

Vampire

02/02/2023, 4:00 PM
I gues for Native it is not relevant?
I don't know, I don't do native
m

mike.holler

02/02/2023, 4:00 PM
I don't know, don't do native
I wish I could say that 😂
Thanks guys. I'll try out these switches and knobs.
Glad I don't have to do composite builds. That is huge overkill I'm happy to avoid.
v

Vampire

02/02/2023, 4:02 PM
Maybe the link I gave was only for not-multiplaform but the targeted plugins where no native is available
a

Adam S

02/02/2023, 4:02 PM
the Gradle config DSL is sometimes a little different for different targets, but this should work
Copy code
tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach {
  kotlinOptions {
    apiVersion = "1.7"
  }
}
v

Vampire

02/02/2023, 4:02 PM
Composite builds is not really overhead
I think for multi-platform it is just supported for everything, here the right docs page: https://kotlinlang.org/docs/multiplatform-dsl-reference.html#language-settings
m

mike.holler

02/02/2023, 4:04 PM
Good find thanks @Vampire
v

Vampire

02/02/2023, 4:04 PM
So you can even configure it differently on different source sets there
m

mbonnin

02/02/2023, 4:55 PM
Multiplatform composite build are still pretty much in-flight so use at you're own risks. And I think to remember
languageVersion
doesn't work for at least JS (don't quote me on that, the situation is complex)
If you're doing multiplatform, I'd rather ask your users to update to Kotlin 1.8 (or keep using older versions of your SDK)
As of 1.7,
languageVersion = 1.6
wasn't working for at least native (source), pretty sure it's the same situation for JS
Maybe 1.8 is better, let us know if it works!
m

mike.holler

02/02/2023, 5:01 PM
The situation is actually quite a bit more complex than I've let on. We're doing some compiling of native sources and including them in our build via Touchlab's cklib. The behavior of the generated code is changed and I suspect it may be a result of the wrapping that is going on for it. As such, the languageVersion and apiVersion options did not work, and composite builds seem like the answer. Unfortunately, with that information, it seems like we may have to keep this stuff in a separate repository altogether and include it as a separate versioned artifact from our artifact repository.
Updating from 1.7.10 to 1.8 seems to have not worked with cklib and whatever's going on there.
If there are other mechanisms of including
.cpp
sources I'm all ears, but this is where I'm at right now.
I'm almost ready to test the included build, so I'll have an answer on that soon
m

mbonnin

02/02/2023, 5:05 PM
But TBH I'd ask MPP consumers to upgrade. MPP is still pretty much the bleeding edge so you gain a lot by using latest versions everywhere
It's not like JVM where some orgs are stuck with servers on Java8. Orgs that use MPP are usually a lot more agile
m

mike.holler

02/02/2023, 5:06 PM
@mbonnin this is an issue with compiling of native files into a lib. It fails after upgrade, is the problem.
Very nuanced case
m

mbonnin

02/02/2023, 5:06 PM
Ah, gotcha!
m

mike.holler

02/02/2023, 5:06 PM
Until we can figure out a way away from cklib I think we may be stuck compiling that targeting 1.7.10
m

mbonnin

02/02/2023, 5:07 PM
Might be worth filing an issue on cklib?
m

mike.holler

02/02/2023, 5:08 PM
It's borderline abandoned now...
m

mbonnin

02/02/2023, 5:08 PM
arf
m

mike.holler

02/02/2023, 5:08 PM
Yeah
This whole system is a mess, but it has to be in a way. We're providing a KMP FlatBuffers DSL for our specific schema (performance sensitive project) and the result is that we need to generate
.cpp
,
.java
, and
.js
code from our
.fbs
schema (think
.proto
) and then write a common wrapper that delegates to each platform's implementation library.
2 Views