Has anyone found guidance on applying freeCompiler...

# gradle

[leandro]

Has anyone found guidance on applying freeCompilerArgs for a multi-module, KMP project using convention plugins?

[Javier]

What is the problem? It should be the same than in jvm projects 🤔

[Leon Linhart]

Assuming you are applying the Kotlin Multiplatform plugin in your convention plugin, you can just use the DSL as usual. For example:

targets.configureEach {
    compilations.configureEach {
        compilerOptions.options.apiVersion.set(KotlinVersion.KOTLIN_1_8)
        compilerOptions.options.languageVersion.set(KotlinVersion.KOTLIN_1_8)
        compilerOptions.options.freeCompilerArgs.add("foo")
    }
}

[leandro]

@Javier I'm gradle noob hah always see people applying with tasks.withType, or targets like Leon posted above... but it's not clear to me if there was a more correct approach

[Javier]

Which version of kotlin are you using?

[Javier]

one of the latest versions added compilerOptions to the kotlin dsl

[leandro]

1.8.21... yeah I'm aware of the kotlinOptions to compilerOptions, but to add to the complexity, I can't find compilerOptions if I do

tasks.withType<org.jetbrains.kotlin.gradle.dsl.KotlinCompile<*>>() {
  ...
}

[Javier]

you are not importing the correct value

[Javier]

image.png

[Javier]

I thought they added compilerOptions to the kotlin dsl

kotlin {
    compilerOptions {
        ...
    }
}

But maybe it will be on 1.9 or 2.0? Or maybe I am drunk cc @tapchicoma

[Leon Linhart]

The compilerOptions DSL is used in my example above. It is not available on the top-level kotlin extension and I don't know if there are any plans to change that.

Don't use org.jetbrains.kotlin.gradle.tasks.KotlinCompile as this class is only used for JVM targets. If you want to configure the compile tasks directly use org.jetbrains.kotlin.gradle.tasks.AbstractKotlinCompile instead. However, there is no practical difference between my approach and this one.

[Javier]

as this class is only used for JVM targets

Are you sure about that? I think that is not correct

[Leon Linhart]

Are you sure about that?

Yes. I don't have a source to cite at hand but it's obvious when you look at the source code. Compare, for example, Kotlin2JsCompile.

[Javier]

Indeed I am thinking now that I haven't use it for something that is not JVM related, as context receivers doesn't work on KMP.

[tapchicoma]

kotlin.compilerOptions { .. } was added in 1.9.0 for Kotlin/JVM and Kotlin/Android plugins only. Kotlin/MPP should be added in 1.9.20 release

[leandro]

Kotlin/MPP should be added in 1.9.20 release

Does that mean I can do something like starting from 1.9.20:

extensions.configure<KotlinMultiplatformExtension> {
  compilerOptions {
    freeCompilerArgs += listOf()
  }
}

and is this better than configuring with tasks.withType?

[tapchicoma]

yes

[Javier]

Indeed probably you can

extensions.configure<KotlinProjectExtension> {
  compilerOptions {
    freeCompilerArgs += listOf()
  }
}

so you can reuse the same configuration in any Kotlin project, not only KMP

[leandro]

That's true, that's what I did: on my KMP convention I get as extensions.configure<KotlinMultiplatformExtension>, on my KotlinAndroid convention I get as extensions.configure<KotlinAndroidProjectExtension>. I then share a configuration that receives extension: KotlinProjectExtension as supertype

[efemoney]

If you want to configure the compile tasks directly use org.jetbrains.kotlin.gradle.tasks.AbstractKotlinCompile instead

Please dont, the DSL task is KotlinCompilationTask .

Better still don’t use the task at all (from 1.9.20, use compilerOptions directly from the kotlin extension)

[Leon Linhart]

Looks like KotlinCompilationTask was added alongside the compilerOptions DSL and I missed it. Thanks for pointing this out.

[Leon Linhart]

https://kotlinlang.org/docs/gradle-compiler-options.html