Hi, we just made a release at <https://github.com/...
# ksp
j
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.
👍 8
z
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?
repro is https://github.com/ZacSweers/MoshiX, running
./gradlew :moshi-ksp:tests:test
no longer appears to run KSP and generate any subsequent code
1
e
running into the same thing, tried updating ksp and now no code is generated
z
quick update, reverted the update on my repo, use this link https://github.com/ZacSweers/MoshiX/tree/324c8e03f2f61d3b4a0953687d5706968a35954b
j
Thanks for reporting.. I’ll file a bug for tracking
t
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.
z
I'll give that a shot
t
Thanks. I have a patch ready and will make another release tomorrow.
👍 2
j
What is the benefit of moving KSP to a seperate task?
z
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
t
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.
Secondly, incremental compilation in kotlin is done iterative. For example, it may compile A.kt and then find that B.kt need to be compiled as well, and then in the third iteration compile C.kt. In the planned model of symbol processing, we try not to deviate from annotation processing too much and want to provide all inputs at once.
Of course, if it's widely acceptable that all processors are "isolating" in KSP, then the second point in the above wouldn't be a problem. And then we can try to change the compiler a little bit and merge KSP back to the compilation task.
z
is merging it back in a goal or a nice-to-have-down-the-line-maybe?
t
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.
z
Kapt would disagree with the second bit :X
t
It's more like the later to me.
May I know why?
z
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
t
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.
z
and I'm optimistic, but would want to see benchmarks before I could recommend wider adoption within our team as every solution in kotlin I've seen involving extra kotlinc invocations has quickly become a bottleneck (ABI jar gen, kapt, etc)
t
Thanks for letting me know the caching issue. It looks like a bug to me. We'll keep that in mind when implementing ksp.
The overhead caused by moving to a separate task is around 150ms on my machine. We'll prioritize reducing / eliminating it if we decided to move to a kotlinc incremental compilation compatible model.
👍 1