would you ever consider allowing KSP to run embedd...

# ksp

[Zac Sweers]

would you ever consider allowing KSP to run embedded directly in kotlinc again? I understand why it's a separate task now, but I also wonder if that's something that could be configurable if none of the given processors require it. We're using Anvil pretty heavily (which wires into the same infrastructure) and the easy of just having it directly in the existing kotlinc tasks makes it really appealing to write new code generators using its infra rather than KSP

[Ting-Yuan Huang]

May I know what the inconvenience of running KSP in a separate task is, besides the slight overhead?

Ivan and I discussed about some changes in the compiler to merge KSP back into compiler's task but we don't have a concrete plan nor schedule yet.

[Zac Sweers]

The overhead is the issue

[Zac Sweers]

I trust kotlin IC and gradle compilation avoidance less the more tasks there are. Even if the happy path is slight overhead, I’ve found kotlin and gradle to be too sensitive to classpath changes and easily invalidated

[Ting-Yuan Huang]

Theoretically, running in a separate task doesn't invalidate extra things and shouldn't make IC / compilation avoidance less efficient, in any cases. Most likely, moving it back to the compilation task won't eliminate the issues; The bugs would shift from Gradle into the compiler, because it's then compiler finding stale sources instead of Gradle for new classpaths / sources introduced by KSP.

[Zac Sweers]

Gradle and KGP "theoretically" do a lot of things 🙂

[Zac Sweers]

I disagree - classpath properties in AbstractCompile tasks are notoriously finicky

[Zac Sweers]

and KGP's incremental IC is more reliable at least than gradle is in this department