bazelbuild
Support KSP annotation processing
First pass at supporting KSP annotation processing as an alternative to Kapt.
This PR runs KSP as part of the existing KotlinCompile action so that Kotlinc only has to be invoked once while compiling a target. We could optionally pull this out into a unique action, like we do for Kapt, at the cost of re-processing Kotlin sources.
I've been planning on moving my Kotlin Gradle project to Bazel lately, but Bazel's support for Kotlin ecology seems imperfect, so I'm just curious if KSP can't be implemented like Jetpack Compose? Just apply the Kotlin compiler plugin, because essentially, KSP is just a KCP plugin
I've been planning on moving my Kotlin Gradle project to Bazel lately, but Bazel's support for Kotlin ecology seems imperfect, so I'm just curious if KSP can't be implemented like Jetpack Compose? Just apply the Kotlin compiler plugin, because essentially, KSP is just a KCP plugin
@RinOrz it should theoretically be possible. I took this approach because I was interested in at a lower level so that we could play around with performance a bit more (Ex: Running KSP in a standalone action like we do for kapt vs running as part of the existing Kotlin compile).
What's the status of this? Is there any way I could help?
Definitely needs some more testing. We are moving over our annotation processors over the KSP internally and will hopefully have something to report back with in the coming weeks.
My hope here is that we don't actually need to build this into rules_kotlin and that we can just lean into the existing Kotlinc plugin infrastructure that exists.
@Bencodes have you considered whether KSP can be used in a target that also runs KAPT, and if so, if KSP & KAPT can depend on each other's outputs? Looking at https://github.com/google/ksp/issues/863 that decision hasn't been made yet in Gradle-land.
@lukaciko that's not a case that we've accounted for and not sure if we do. This seems like something that would add a lot of complexity to our annotation processing, and even introduce some clashing between the two.
@Bencodes I think it's fair enough if it is not supported, as long as that's clear and explicit. I'd like to avoid one of those cases where something is accidentally supported in one version of the rules and gets dropped in another.
I took another stab at getting a less intrusive version of KSP working yesterday. This approach does work and it comes with the added benefit of us not needing to couple KSP to rules_kotlin.
https://github.com/bazelbuild/rules_kotlin/pull/829