Proposal: Enable independent code generation for every source set, decoupling KSP invocations from Kotlin compilations

[OliverO2]

Related

• IDE not indexing generated source #37
• Generating common code #567
• How to generate code across sourcesets #799
• Question: Produce on test sources #962
• How to generate code for common Ios target instead of individual (X64, Arm64) source sets #929

To Consider

• Specifics on Android build variants and impacting the Gradle build cache: IDE not indexing generated source #37 (comment)

Prerequisites

• Improve Multiplatform Support With Source Set-Based Configuration #1021
• Support source set-specific code generation in Multiplatform projects #965

Background

Kotlin Multiplatform compilation

This is how Kotlin multiplatform compilation currently works (based on input from the JB Kotlin Multiplatform team):

Given a hierarchy of source sets and calling the leaves "target source sets", the Kotlin Gradle multiplatform plugin will create Kotlin compilations for these source sets:

1. commonMain
2. each target source set (e.g. jvmMain, jvmTest, jsMain, jsTest)
3. each intermediate source set if it is shared across two or more target source sets

NOTE: Shared test source sets never receive their own compilation.

Examples

Example A

Given the following source set hierarchy:

• commonMain
  • clientMain
    • jvmMain

There will be one Kotlin compilation for commonMain, and one for jvmMain. clientMain will not have its own compilation as it is not shared across multiple targets.

Example B

Now change the source set hierarchy like so:

• commonMain
  • clientMain
    • jvmMain
    • jsMain

The will be one Kotlin compilation for commonMain, one for clientMain, one for jvmMain, one for jsMain.

KSP Multiplatform operations

With #1021 merged, KSP can be configured per source set. A companion KSP task will be created for each Kotlin compilation, given its source set has an active KSP configuration.

If KSP is configured for commonMain and that configuration is inherited, there will be one KSP invocation per Kotlin compilation:

Example A will not have a KSP invocation for clientMain. That means

• Whatever KSP should process for clientMain must be incorporated in its invocation for jvmMain.
• KSP cannot output clientMain-specific code in its own output directory (it would output such code in the jvmMain output directory).

Example B will have a separate KSP invocation for clientMain, along with its own output directory for clientMain.

Current Limitations Within The IDE

If KSP generates code from annotations in parent source sets, and that code is output in a target source set directory, there is currently no way to correctly tell the IDE where to find such code.

Example

As shared test source sets never have their own KSP invocation, a KSP processor will typically generate identical code for each target source set depending on the same parent source set.

E.g., code generated for commonTest will appear in jvmTest and jsTest.

Proposed Solution

Decouple KSP invocations from Kotlin compilations, allowing separate KSP invocations and separate KSP output directories for

• parent source sets which are not shared across two or more targets,
• parent test source sets.