<@U014RF7ANH5> may I make a suggestion in terms of...

# ksp

[Matthias Geisler]

@Jiaxiang may I make a suggestion in terms of KMP? Do you want it as issue or you like to chat here about?

[Jiaxiang]

we can start with a chat here and formalize the discussion result into an issue

[Matthias Geisler]

Cool - as I think to get the point with the trouble why KSP is not aware of shared sources/meta sources like commonTest, it should be resolvable by consumers. Iff I got it correctly it would be sufficient to provide the CodeGenerator with the additional information via createNewFile so it can simply exchange it when it invokes pathOf. Not sure how it affects associate or associateWithClasses since I am not totally sure what they are exactly meant for, but it should work similarly.
The propagation could be either be done via `Dependency`(however I am not sure it is a good fit), or directly with an additional arg of the mentioned methods. To comply with the folder structure this argument must be the full name of the sourceSet which gets strip down (commonTest -> common).
I currently make a custom implementation of the CodeGenerator which is basically a strip down version of CodeGeneratorImpl but cannot make use of the sweet features which come with the internal Generator. So I think KSP could do it directly.
Well, what do you think?

[Alex Vanyo]

I think this might make sense to add to https://github.com/google/ksp/issues/567, as a related issue for generating common code. I agree that the current setup isn’t as flexible as it could be.

[Matthias Geisler]

A 2nd alternative in my eyes is to introduce Factories for CodeGenerators, which simply takes the arguments which CodeGeneratorImpl gets currently on its constructor. This solves the problem indirectly since consumers can implement their own Generator with additional capabilities while not necessarily losing any features which comes with the internal Generator. The factories could be similar propagated like a processor to KSP. This way is even more flexible but pushes all responsibility on consumers. Either way I am willing to contribute if wanted.

[Matthias Geisler]

Before this discussion falls asleep - here is the custom CodeGenerator. If you look over the project itself this still plays in tandem with KotlinPoet for example here. More importantly it works just fine with KMP.

[Ting-Yuan Huang]

the trouble why KSP is not aware of shared sources/meta sources like commonTest

Do you mean:
1. generated code / computation done by processors can't be shared, or
2. commond code can't be processed separately from target code?

[Matthias Geisler]

Its not only commonTest - I also think about nativeTest, iosTest or other arbitrary shared sources/meta sources created by users.

[Matthias Geisler]

And I mean the CodeGenerator is currently not able to select right target for shared sources/meta sources like mentioned above. Thats also what the issue describes mentioned by Alex Vanyo.

[Ting-Yuan Huang]

KSP currently follows Kotlin MPP's compilation model, which compiles shared sources sets multiple times with target specific source sets. Therefore there should be no need to specify target in CodeGenerator: Shared source sets are presented to processors along with target source sets so all the information is available, and generated codes are only visible to the compilation of that target. The drawback is, obviously, performance. But, it is simple and less error prone.

Changing the compilation / processing model (explicitly or implicitly like your proposal) will likely introduce substantial incompatibilities (to past or future) and therefore we need to be extra careful. On the other hand, Kotlin MPP is theoretically in alpha stage and things are subject to change anyways. We'd like to move carefully and update KSP's model when Kotlin MPP gets stabilized, so that we won't break people's projects too many times.

Sorry for the late reply. We do keep an eye on this and will address it.

[Matthias Geisler]

I appreciate your statement! Also I completely understand your hesitance.
As you describe:

KSP currently follows Kotlin MPP's compilation model, which compiles shared sources sets multiple times with target specific source sets.

Thats what I meant in the beginning at this thread - I get that totally. The point here is the compiler are totally happy with that, but developers will not, since a IDE will not be able to resolve generated sources correctly unless they are put in the correct source folder.
Since the CodeGenerator is technically not involved in the analysis process, it will not interfere with KSP primary logic. Additionally KSP already exposes the Interface of the CodeGenerator, so technically it is already possible to exchange it with a custom one (like I did), but the optimisations are gone. While I get your point with incompatibilities, I think more and more my 2nd proposal is the better one (aka Factory), since it would allow still to differ between an intern implementation and consumer induced one, but providing consumers with tools to keep the optimisations like the internal Generator. This might keeps also problems with incompatibility at bay.
Summa summarum - I'd like either to somehow tell the CodeGenerator where to put sources or to get the tools (I believe that has something to do with here) to behave similar to the internal one.
However in the end you have to decide and I appreciate any solution, which does not fall behind the current possibilities.