Probably a stupid question. Is it possible to have different gradle sub-projects with different Kotl...

# gradle

[mike.holler]

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?

[Vampire]

I think you can use the 1.8 Gradle plugin and configure the language level for B using configuration

[mike.holler]

Can you elaborate on "configure the language level"?

[mike.holler]

Note that this is a multiplatform project, so I'm not talking about JVM version.

[Vampire]

https://kotlinlang.org/docs/gradle-compiler-options.html#attributes-common-to-jvm-and-js

[Adam S]

why do you want to use different Kotlin versions?

[Vampire]

There is apiVersion add languageVersion to configure

[mike.holler]

SDK needs to support clients using lower Kotlin versions than our server.

[Adam S]

yeah, that’s what apiVersion is for 👍

[mike.holler]

Attributes common to JVM and JS

Not native?

[CLOVIS]

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

[Vampire]

I gues for Native it is not relevant?

[Vampire]

I don't know, I don't do native

[mike.holler]

I don't know, don't do native

I wish I could say that 😂

[mike.holler]

Thanks guys. I'll try out these switches and knobs.

[mike.holler]

Glad I don't have to do composite builds. That is huge overkill I'm happy to avoid.

[Vampire]

Maybe the link I gave was only for not-multiplaform but the targeted plugins where no native is available

[Adam S]

the Gradle config DSL is sometimes a little different for different targets, but this should work

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach {
  kotlinOptions {
    apiVersion = "1.7"
  }
}

[Vampire]

Composite builds is not really overhead

[Vampire]

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

[mike.holler]

Good find thanks @Vampire

[Vampire]

So you can even configure it differently on different source sets there

[mbonnin]

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)

[mbonnin]

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)

[mbonnin]

As of 1.7, languageVersion = 1.6 wasn't working for at least native (source), pretty sure it's the same situation for JS

[mbonnin]

Maybe 1.8 is better, let us know if it works!

[mike.holler]

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.

[mike.holler]

Updating from 1.7.10 to 1.8 seems to have not worked with cklib and whatever's going on there.

[mike.holler]

If there are other mechanisms of including .cpp sources I'm all ears, but this is where I'm at right now.

[mike.holler]

I'm almost ready to test the included build, so I'll have an answer on that soon

[mbonnin]

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

[mbonnin]

It's not like JVM where some orgs are stuck with servers on Java8. Orgs that use MPP are usually a lot more agile

[mike.holler]

@mbonnin this is an issue with compiling of native files into a lib. It fails after upgrade, is the problem.

[mike.holler]

Very nuanced case

[mbonnin]

Ah, gotcha!

[mike.holler]

Until we can figure out a way away from cklib I think we may be stuck compiling that targeting 1.7.10

[mbonnin]

Might be worth filing an issue on cklib?

[mike.holler]

It's borderline abandoned now...

[mbonnin]

arf

[mike.holler]

Yeah

[mike.holler]

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.