Support source set-specific code generation in Multiplatform projects

As shown in #963, this repository’s multiplatform example generates identical code for all source sets, resulting in “Redeclaration” compiler errors once dependencies are set up correctly. While this example can be fixed by generating code for the commonMain source set only, this will not work with projects requiring separate code sets generated for different source sets.

OliverO2/kotlin-multiplatform-ksp contains an example project where this problem has been solved via source set detection:

https://github.com/OliverO2/kotlin-multiplatform-ksp/blob/214eef9e529ca3dae8a6e38123790b4795302969/symbol-processor/src/jvmMain/kotlin/QualifiableProcessor.kt#L37-L38

https://github.com/OliverO2/kotlin-multiplatform-ksp/blob/214eef9e529ca3dae8a6e38123790b4795302969/symbol-processor/src/jvmMain/kotlin/QualifiableProcessor.kt#L55-L56

As there seems to be no reliable API providing the required information on input and output source sets, the solution is unstable.

In addition, the output source set is only detected via the codeGenerator’s generated file path, which makes it unsuitable for collecting information before deciding on code generation.

Would it seem feasible for a future KSP release to provide information on input and output source sets via the SymbolProcessorEnvironment or the Resolver?

[neetopia]

Sorry I am currently packed with other tasks, will reach back (also follow up on your PR) probably next week.

[OliverO2]

Excluding (human written) parent sources from getNewFiles/getAllFiles/getSymbolsWithAnnotation/etc. would immediately solve use case 1 (generate code from symbols in its current (output) source set only). It would not cover use case 2 (generate expect/actual code, triggered by annotations in a shared source set). The latter would require full source set-awareness in the processor and complete access to parent source set symbols.

If a processor is to generate some (non-trivial) source set-specific code, it must have some idea about the source set’s targets and know which (library) APIs are available. Such information could be conferred via source set-specific configuration (arg option) or determined via the (hardwired) source set name in the processor itself. For completeness, we’d have to keep in mind the edge case of #1037, when there might not be a separate compilation for some intermediate source sets.