https://kotlinlang.org logo
Title
z

Zac Sweers

12/24/2020, 12:40 AM
is there any scenario where
dependOnNewChanges
would be false?
t

Ting-Yuan Huang

12/24/2020, 12:44 AM
Yes. For example, in java / kapt's world, no outputs of an isolating processor depend on new changes.
z

Zac Sweers

12/24/2020, 12:45 AM
could you unpack that a bit more?
t

Ting-Yuan Huang

12/24/2020, 12:48 AM
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

Zac Sweers

12/24/2020, 12:49 AM
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

Ting-Yuan Huang

12/24/2020, 12:51 AM
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

Zac Sweers

12/24/2020, 12:52 AM
hmm, ok I think I had my thinking flipped
t

Ting-Yuan Huang

12/24/2020, 12:52 AM
Maybe we should rename it to
dependsOnNewFiles
?
z

Zac Sweers

12/24/2020, 12:52 AM
possibly. Does that exclude new files that would normally otherwise qualify for processing if they contain relevant annotations?
t

Ting-Yuan Huang

12/24/2020, 12:56 AM
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

Zac Sweers

12/24/2020, 12:56 AM
gotcha. So by default, it should really be
false
in most cases?
t

Ting-Yuan Huang

12/24/2020, 12:58 AM
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

Zac Sweers

12/24/2020, 1:01 AM
yeah... I'm confused again 😅
I think I just need to see an example of each
t

Ting-Yuan Huang

12/24/2020, 1:02 AM
In fact, the correspondence is used to propagate dirtyness. You may think of outputs as links when propagating dirtyness from source to source.
z

Zac Sweers

12/24/2020, 1:03 AM
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

Ting-Yuan Huang

12/24/2020, 1:03 AM
re: examples: will do! thanks for the questions, that helped my document a lot 🙂
z

Zac Sweers

12/24/2020, 1:04 AM
it's "aggregating" in normal apt/kapt contexts I think, but I'm not sure what to do in the KSP case
t

Ting-Yuan Huang

12/24/2020, 1:06 AM
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

Zac Sweers

12/24/2020, 1:08 AM
👍 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

Ting-Yuan Huang

12/24/2020, 1:10 AM
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

Zac Sweers

12/24/2020, 1:46 AM
those examples are a bit too abstract for me
t

Ting-Yuan Huang

12/24/2020, 1:46 AM
Let me try again with github's markdown.
z

Zac Sweers

12/24/2020, 1:47 AM
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

Ting-Yuan Huang

12/24/2020, 1:52 AM
dependsOnNewChanges
should be
false
in this case, because each existing output doesn't depend on new information.
z

Zac Sweers

12/24/2020, 1:52 AM
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

Ting-Yuan Huang

12/24/2020, 1:54 AM
dependsOnNewChang = true
for that relevant outputs.
z

Zac Sweers

12/24/2020, 1:54 AM
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

Ting-Yuan Huang

12/24/2020, 1:56 AM
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

Zac Sweers

12/24/2020, 1:57 AM
yeah that's what I was suggesting
t

Ting-Yuan Huang

12/24/2020, 1:57 AM
or simply
aggregating
👍 1
Cool, thanks for fish-food the API 🙂
z

Zac Sweers

12/24/2020, 1:58 AM
happy to help 👍