Trying to wrap my head around incremental processing. I'm currently in a situation where changing th...

# ksp

[mbonnin]

Trying to wrap my head around incremental processing. I'm currently in a situation where changing the KSP classpath processed sources classpath invokes my processor but somehow resolver.getAllFiles() return no files (not sure if expected?).
The processed source files did not change but given my processor implementation did, shouldn't a full rebuild be done?. Is it expected that my processor is still called if nothing changed in the processed source files?

[mbonnin]

Comparing to another working project, the difference is that the working project has this line:

The input changes require a full rebuild for incremental task

when the non-working one doesn't

[mbonnin]

Working:

Input property '$1' file /Users/mbonnin/git/test-ksp/processor/build/libs/processor.jar has changed.
The input changes require a full rebuild for incremental task ':app:kspKotlin'.

Not working:

Input property 'classpathSnapshotProperties.classpath' file /Users/mbonnin/git/apollo-kotlin/libraries/apollo-api/build/libs/apollo-api-jvm-4.0.0-beta.2-SNAPSHOT.jar has changed.

[mbonnin]

Alright, I was wrong, the KSP classpath didn't change, it's the classpath of the analyzed sources that did. That clears it up.

[mbonnin]

Still curious if calling the processor altogether could be avoided if nothing changed

[Ting-Yuan Huang]

Processors can be called when there is no source change, when some of the outputs can possibly be based on classes in the compile classpath. The determination logic has to consider all possibilities and be conservative, so sometimes there are false positives.

Setting the gradle property ksp.incremental.log=true and looking at build/kspCaches/<target>/<source set>/logs might give some hints on why the processors are called.

[mbonnin]

It says this:

All Files
  src/main/kotlin/com/apollographql/apollo/sample/server/Main.kt
  src/main/kotlin/com/apollographql/apollo/sample/server/SampleServer.kt
  src/main/kotlin/com/apollographql/apollo/sample/server/graphql/MutationRoot.kt
  src/main/kotlin/com/apollographql/apollo/sample/server/graphql/QueryRoot.kt
  src/main/kotlin/com/apollographql/apollo/sample/server/graphql/SubscriptionRoot.kt
Modified
Removed
Disappeared Outputs
Affected By CP
Affected By new syms
Affected By sealed
CP changes
Dirty:

Dirty / All: 0.00%

[mbonnin]

But it makes sense to give more control to the processor rather than not

[Ting-Yuan Huang]

If your processor doesn't use Resolver.getClassDeclarationByName, then it is a false positive.

[mbonnin]

It does not

[mbonnin]

It's ok though, was mostly curious, I don't mind at all 🙂

[Ting-Yuan Huang]

It may be possible to optimize the call to processor away if KSP tracks the usage of getClassDeclarationByName. On the other hand, most of the processor would have very little overheads when there is no input source at all. The gain would be minimal.

[mbonnin]

Does getClassDeclarationByName look into dependencies?

[mbonnin]

Find a class in the compilation classpath for the given name

[mbonnin]

Ah, yes it does, gotcha 👍

[mbonnin]

Well it makes a ton of sense, thanks for the insight 🙏