I'm updating one of my processors to use the latest KSP and now a test is failing. The test in quest...

# ksp

[ansman]

I'm updating one of my processors to use the latest KSP and now a test is failing. The test in question tests incremental compilation. It adds a file, compiles, then removes the file and adds another and compiles again. What happens is that files generated from the first file remains but now fails to compile. Is there a known issue wrt to this? It fails even if I don't enable incremental KSP

[Ting-Yuan Huang]

Is it ksp 1 or 2?

[ansman]

KSP2

[ansman]

I'm using Kotlin Compile Testing, I see that modifiedSources, removedSources and changedClasses are all empty

[Ting-Yuan Huang]

Incremental compilation requires cooperation between build system and compiler. In KSP, it's KSP Gradle plugin's responsibility to remove all generated files before calling into KSP [1], incremental or not. Please make sure that Kotlin Compile Testing removes all generated files in the previous build before calling KSP.

[1] KSP keeps copies of generated files and restore them when re-processing isn't needed. It assumes that it is provided clean output directories when called.

[ansman]

Yeah that was indeed the issue. For incremental processing to work, does the removed files, changed classes and files need to be set?

[Ting-Yuan Huang]

Yes, that are the roots of dirty files / classes. Files need to be specified if they are removed or modified. Newly added files count toward modified.

Binary classes in dependencies / classpath, if changed, need to be passed in KSPConfig.changedClasses, using their fully qualified names. Note that not only the changed classes need to be specified, all classes that reference them need to be specified as well, transitively. In KSP Gradle plugin, only the JVM backend supports this. On other targets, changes in libraries simply trigger a full rebuild.

[ansman]

Got it, thanks! @Zac Sweers this would be supportable in KCT, would you be open to a PR?