Is there a way to change the KSP task input dependencies? Specifically we have modules A, B and C wi...

# ksp

[quicksteve]

Is there a way to change the KSP task input dependencies? Specifically we have modules A, B and C with C depending on A & B, but declaring only methods using A. KSP still waits for both A & B to compile though. As a workaround we currently have a submodule of C, which declares just A as a dependency containing a Sync task which copies all the parent kotlin sources to a temporary directory, then have the KSP task run with that.

[Oliver.O]

By saying "KSP still waits for both A & B to compile though" do you mean KSP does not process A before the Kotlin compiler compiles A?

[Oliver.O]

And do you use Kotlin multilpatform or the Android build plugin?

[quicksteve]

Yes, that is what I mean, I'm not using multiplatform/Android (we are developing a JVM Backend)

[Oliver.O]

Normally, each compileXXX task depends on its corresponding kspXXX task (as it needs the generated KSP files). If that is not the case, did you try to configure it manually, like compileXXX.dependsOn(kspXXX)?

[quicksteve]

Wait, sorry. KSP is only processing C, not A or B. But to process C it first runs compile for A and B, even though it is only necessary to wait for A

[Oliver.O]

Hmm, then it looks like what I'd expect at the task level. If compile task C depends on A&B, then KSP task C (as a compiler plugin) should also depend on A&B since it is using the compiler. Remaining optimizations (incremental compilation) should occur inside the compiler and do not surface at the Gradle task level. It least that's my understanding.

[quicksteve]

But if I perform the dance outlined in my initial post, it is fine - and I don't need to wait for B (e.g. compile B and KSP C can run in parallel)

[Oliver.O]

Yes, that's because you are telling Gradle to skip the B dependency for KSP, then re-introduce it later. If that works for you currently, why not keep it?