Hi, we just made a release at https://github.com/google/ksp/releases/tag/1.4.10-dev-experimental-20201106 Highlights • KSP is now in a separate task from the main kotlinCompile task, which allows you to run ksp alone. • Now you can generate class files to be included in kotlin compile. • Now you can write test in KSP repo for multiple module use cases, good for testing dependency related issue. (Credit to @yigit !) • As a prerequisites of KSP multiple round processing, we added a symbol validation API for validating types in a symbol’s enclosed scope. See 

KSNode.validate()

 for more details.

I'm unable to get KSP to run via gradle alone, it seems to completely miss appropriate wiring and never gets run even if I run the ksp task directly. Did any project structure requirements change?

running into the same thing, tried updating ksp and now no code is generated

quick update, reverted the update on my repo, use this link https://github.com/ZacSweers/MoshiX/tree/324c8e03f2f61d3b4a0953687d5706968a35954b

Thanks for reporting.. I’ll file a bug for tracking

Somehow the dependency in

ksp(....)

is missing and therefore the processor might not be ready when needed. A temporary workaround would be appending

compileOnly(...)

along with

ksp()

. I'm still investigating why it is missing.

I'll give that a shot

Thanks. I have a patch ready and will make another release tomorrow.

What is the benefit of moving KSP to a seperate task?

I'm curious as well, seems to sort of go against the original goal of running as a compiler plugin in the same compilation. A big part of why kapt is slow is because it's a separate task and thus a separate (even if faster) compilation

The main reason is that incremental compilation model is incompatible with symbol processing's. First, the dirty sets are different. It's possible to use the union of the two dirty sets but that would introduce too much unnecessary recompilation and reprocessing in both side.

is merging it back in a goal or a nice-to-have-down-the-line-maybe?

On the performance of a separate task: There are two overheads that I know of. The first is the creation of the gradle task. This should be fine. The second is the invocation of the compiler. This is fine, too, because of the KotlinCompileDaemon.

Kapt would disagree with the second bit :X

It's more like the later to me.

KotlinCompile tasks are non-trivial overhead, prone to broken build caching, and more. I'd be curious to see updated benchmarks with the separate task, but I suspect it would be roughly the same speed as a kapt-using project but minus the stubs task

I don't know about the prone to broken build caching part. As for the overhead of KotlinCompile, I agree that it's non-trivial, but I think it is also pretty small when compared to stub generation and processing itself. The other thing that ksp has an edge over kapt is incremental processing. Unlike kapt, which need to be conservative because it determines the dependencies statically, the dependencies in ksp are tracked dynamically. Therefore the dirty set in ksp should be much smaller than kapt and we hope that would translate to lower processing time.

this is the caching issue https://youtrack.jetbrains.com/issue/KT-34862

Thanks for letting me know the caching issue. It looks like a bug to me. We'll keep that in mind when implementing ksp.