https://kotlinlang.org logo
Join Slack
Powered by
is there any scenario where `dependOnNewChanges` w...
# ksp
z
is there any scenario where 
dependOnNewChanges
would be false?
t
Yes. For example, in java / kapt's world, no outputs of an isolating processor depend on new changes.
z
could you unpack that a bit more?
t
It is a flag to specify whether the output being created should depend on new changes. It is not whether this processor should depend on new changes, because the latter is always true. In isolating processors, each output file has exactly one originating source. So if this source isn't changed (or affected for some reason), this output is up-to-date.
z
what's an example of a case where changes to the file wouldn't want to cause a regenerated file?
struggling to wrap my head around this
t
If a file is changed, then it'll always be reprocessed and corresponding files are always regenerated. 
dependsOnNewCHanges
means new files or changes in other files.
z
hmm, ok I think I had my thinking flipped
t
Maybe we should rename it to 
dependsOnNewFiles
?
z
possibly. Does that exclude new files that would normally otherwise qualify for processing if they contain relevant annotations?
t
Yes. If an output doesn't 
dependOnNewFiles
, it and its inputs has a chance to be skipped. Any outputs depending on new files will cause their inputs to be marked as dirty.
z
gotcha. So by default, it should really be 
false
in most cases?
t
For isolating cases, yes. For aggregating cases, the flag should be true. So there is no default value for that parameter.
Just to be clear, new files or changed files are always subject to reprocessing, regardless of their correspondences to outputs.
z
yeah... I'm confused again 😅
I think I just need to see an example of each
t
In fact, the correspondence is used to propagate dirtyness. You may think of outputs as links when propagating dirtyness from source to source.
z
for example, with my auto-service-ksp processor: https://github.com/ZacSweers/auto-service-ksp/pull/7 Each service file my reference multiple KSFile. If a file changes or a new one is added, I'd want the processor to re-run and regenerate the final source file
t
re: examples: will do! thanks for the questions, that helped my document a lot 🙂
z
it's "aggregating" in normal apt/kapt contexts I think, but I'm not sure what to do in the KSP case
t
In this case, all files referenced plus 
dependsOnNewFiles
should be included, because newly added files or changes in some other existing files may cause them to be included in the future.
I mean, 
dependsOnNewFiles
can be thought of a wildcard, referencing new files or changes in all existing files.
z
👍 cool, I think I get it now. I think I misunderstood earlier and thought that new applicable files would be run regardless of the value
t
New applicable files will still be processed regardless of the value. It is that outputs that don't 
dependsOnNewFiles
won't affect the propagation of dirtyness due to new files. Let me try to build an example.
Let's consider sourceA -> outputA, sourceB -> outputB. when sourceA is changed: If outputB depends on new files: sourceA and sourceB are reprocessed if outputB doesn't depend on new files: sourceA is reprocessed.
Maybe we should change 
dependsOnNewFiles
to 
aggregating/isolating
. It is the same idea as in java, but the scope is per-output rather than entire processor. What do you think?
Another example for new file: in previous case, if sourceC is added, then if outputB depends on new files, or it is aggregating: sourceB and sourceC will be processed if outputB is isolating: sourceC will be processed.
z
those examples are a bit too abstract for me
t
Let me try again with github's markdown.
z
more practical one: Moshi generates one adapter per source class annotated with 
@JsonClass(generateAdapter = true)
Message.kt with 
class Message
results in 
MessageJsonAdapter
generated later two other files are added. One with another json class and another with something unrelated. How does that example fit?
t
dependsOnNewChanges
should be 
false
in this case, because each existing output doesn't depend on new information.
z
gotcha
next example
say I have a processor that generates a factory class that references all the JsonClass-annotated classes in the compilation (so an aggregating processor), which one does that use?
t
dependsOnNewChang = true
for that relevant outputs.
z
gotcha
yeah I think renaming that would help
any reason not to just match semantics people are familiar with and rename it to 
aggregating
?
t
because it is per-output based. Or do you mean why not apply that to entire processor?
Anyway, we'll rename 
dependsOnNewChanges
to 
isAggregating
z
yeah that's what I was suggesting
t
or simply 
aggregating
👍 1
Cool, thanks for fish-food the API 🙂
z
happy to help 👍
3 Views
Open in Slack
PreviousNext
Powered by