Generating common code

[belyaev-mikhail]

If I understand it correctly, "supporting MPP" currently means that KSP can run on all platforms separately, but what if I want to generate common code?
Currently running ksp on an MPP project with common code results in generating the exact same generated code for each platform separately, without any common code generated (or able to generate).
Is generating common code in plans?

[darvld]

I think the kspKotlinMetadata task takes care of generating common code. However I've been having issues with it since it isn't resolving annotations properly. Maybe I'm not using it right though.

[edrd-f]

Hi @belyaev-mikhail. I'm facing a similar issue, but when trying to generate JS code while processing JVM code. My issue is that CodeGenerator does not support specifying the target platform. If this was possible, would it also work for your use case?

[belyaev-mikhail]

Hi @belyaev-mikhail. I'm facing a similar issue, but when trying to generate JS code while processing JVM code. My issue is that CodeGenerator does not support specifying the target platform. If this was possible, would it also work for your use case?

Maybe, depends on the way it's implemented. Basically, one could run ksp on any platform and generate code to common part, that would work for me, but for true MPP projects where there exists some some code in all supported platforms' folders, it may not work.

[edrd-f]

but for true MPP projects where there exists some some code in all supported platforms' folders, it may not work.

I'm not sure I understand why it may not work. Can you explain?

[belyaev-mikhail]

Because if you have, say, a library that contains: a common part, a JVM-specific part and a JS-specific part, you definitely want to generate common code from common part and common part only, which is impossible atm.

[edrd-f]

Well, it's possible, just not that straightforward. I was able to achieve common-only execution of KSP with the following Gradle configuration:

tasks.withType<com.google.devtools.ksp.gradle.KspTaskJS> {
  enabled = false
}

tasks.withType<com.google.devtools.ksp.gradle.KspTaskJvm> {
  enabled = false
}

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> {
  dependsOn(tasks.withType<com.google.devtools.ksp.gradle.KspTaskMetadata>())
}

[evant]

Note: been testing with the new ksp* configurations on 1.0.1-RC, it seems like the metadata task isn't hooked up correctly? I'd expect:

dependencies {
    add("kspMetadata", "...")
}

would generate common code, but instead it does not run. Was able to get it working by hooking up task dependencies & source sets manually:

kotlin.sourceSets.commonMain {
    kotlin.srcDir("build/generated/ksp/commonMain/kotlin")
}
tasks.withType<org.jetbrains.kotlin.gradle.dsl.KotlinCompile<*>>().all {
    if (name != "kspKotlinMetadata") {
        dependsOn("kspKotlinMetadata")
    }
}

[alexvanyo]

Another note for how the kspKotlinMetadata task works in conjunction with other platform tasks:

kspKotlinMetadata runs only against commonMain, which is expected. If you have an entirely pure project (where all code is in commonMain) then @evant 's code snippet above can created common code.

However, let's say you have a non-pure project, where some platform(s) have unique code (code underneath jvmMain, jsMain, etc.). That code won't be processed by kspKotlinMetadata, which also makes sense. If you try to add in processing for platform specific code (such as by adding kspJvm), the platform-specific code gets processed, but the commonMain code gets processed again. For a standard codegen processor, that usually results in duplicate classes for everything that was generated twice.

If each platform only processed code unique to that plaform, and generated code at the same level, I think this situation would be more natural. Under that scenario, kspKotlinMetadata (or maybe that should be kspCommon/kspCommonMain?) would just analyze commonMain code (and output it generated/ksp/commonMain), and kspJvm would just analyze jvmMain code (and output it in generated/ksp/jvmMain)

This is only a guess, but I'm guessing that would also help the situation for hierarchical source sets, where you might want to generate desktopMain code for instance.

[alexvanyo]

Currently, there is also no ksp task for generating code from commonTest

[SalomonBrys]

Currently, there is also no ksp task for generating code from commonTest

This breaks our use case and forces us to revert to processing only "kspJvmTest" and having the generated directory be added to the commonTest source set.

[NyCodeGHG]

The code snippet above is not working for me. Is there a better way for generating common code?

[DRSchlaubi]

Another note for how the kspKotlinMetadata task works in conjunction with other platform tasks:

kspKotlinMetadata runs only against commonMain, which is expected. If you have an entirely pure project (where all code is in commonMain) then @evant 's code snippet above can created common code.

However, let's say you have a non-pure project, where some platform(s) have unique code (code underneath jvmMain, jsMain, etc.). That code won't be processed by kspKotlinMetadata, which also makes sense. If you try to add in processing for platform specific code (such as by adding kspJvm), the platform-specific code gets processed, but the commonMain code gets processed again. For a standard codegen processor, that usually results in duplicate classes for everything that was generated twice.

If each platform only processed code unique to that plaform, and generated code at the same level, I think this situation would be more natural. Under that scenario, kspKotlinMetadata (or maybe that should be kspCommon/kspCommonMain?) would just analyze commonMain code (and output it generated/ksp/commonMain), and kspJvm would just analyze jvmMain code (and output it in generated/ksp/jvmMain)

This is only a guess, but I'm guessing that would also help the situation for hierarchical source sets, where you might want to generate desktopMain code for instance.

kspKotlinMetadata doesn't exist anymore

However what does exist is "kspCommonMainMetadata`, but you cannot add any dependency to that configuration because it can't be resolved