Anyone seen this warning with gradle 7? ```Execut...
# gradle
u
Anyone seen this warning with gradle 7?
Copy code
Execution optimizations have been disabled for task ':radost:user:discount:impl:kspDebugKotlin' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: 'C:\Users\ursus\AndroidStudioProjects\mo2-android\radost\user\discount\impl\build\generated\sqldelight\code\AppDatabase\debug'. Reason: Task ':radost:user:discount:impl:kspDebugKotlin' uses this output of task ':radost:user:discount:impl:generateDebugAppDatabaseInterface' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to <https://docs.gradle.org/7.1.1/userguide/validation_problems.html#implicit_dependency> for more details about this problem.
u
thx
v
Actually from a quick look I'd say that issue is not really related. That issue says that the build of the
sample
project of sqlight has a bug. And the build of ursus has a similar bug. And Gradle 7 started to see and complain about this bug. Staying at ursus message, the task
:radost:user:discount:impl:kspDebugKotlin
has as output the directory
C:\Users\ursus\AndroidStudioProjects\mo2-android\radost\user\discount\impl\build\generated\sqldelight\code\AppDatabase\debug
. The task
:radost:user:discount:impl:kspDebugKotlin
uses this same directory as input, for example because it processes all sources, including the ones generated by the other task. But there is no dependency between the tasks, neither explicit nor implicit, that guarantees their ordering, so if it works correctly, that is just accidental and can change anytime.
m
I'd think these are somewhat related ? It's about declaring generated sources to tasks that are not
compileKotlin
?
Does
SourceDirectorySet.srcDir()
carry task dependencies?
v
It should, yes, for generated sources you should for example just give the generator task in there. But I mean to remember that it was problematic / different with Kotlin. But if that task generates Java sources and their plugin registers it and wires some manual task dependencies, you might be right, yes.
No wait, I think it was not different with Kotlin, it was different with Android
But actually as this is about Android, it would fit
m
For Kotlin, SQLDelight passes a
String
to
srcDir()
: https://github.com/cashapp/sqldelight/blob/e0c21da0a4238a8580f8c45460bf16755270982[…]ain/kotlin/com/squareup/sqldelight/gradle/SqlDelightDatabase.kt so that'd be a pretty good indication that consumers other than
compileKotlin
have no way of knowing about the task dependency
Android being even more complicated. Last time I check it has to do with
registerJavaGeneratingTask
v
Yeah, that's probably bad then. :-( And yes about Android, see here: https://kotlinlang.slack.com/archives/C19FD9681/p1627406611378900
👀 1
That's what I meant previously 🙂
m
I just opened https://github.com/cashapp/sqldelight/pull/2518/files. Let's see if tests go through
v
Maybe also add a test to ensure the behavior doesn't creep back in. 🙂
m
Yep, good point 👍
u
I'm a bit out of my depth here, but just to ask, is this a sqldelight or ksp issue, or their combination? since in only happens in modules where there is both; and I'm kind of surprised ksp takes sqldelight output..does it look for annotations there as well?
v
It probably just processes all source files that are registered and sqldelight generates sources but does not properly register it with task dependency but only by path, so there is no guarantee that the sources are already generated / updated when ksp processes them.
1
You can quick-fix it for your specific build, by adding a
dependsOn
relation and Martins PR will hopefully fix it in the sqldelight plugin actually
u
hmm kspDebugKotlin to depend on generateDebugAppDatabaseInterface?
v
exactly
u
thx, i'll see if it stops complaining then and finally I can use configuration caching after months of ksp breaking it 😄
v
As long as you stay aware that it is highly experimental. 🙂 Besides that this warning is not a CC error, is it?
u
no but it turns off cc for that task, and I think even incremental compile as well since the tasks always get executed even without change or maybe cc works and it simply recompiles the module .. anyways in the end recompile of no changes takes 15seconds, and with everything working and cc as well it should be instant, as it was before I introduced ksp
m
For the record, Android doesn't require
registerJavaGeneratingTask
. Adding to the "main" SourceDirectorySet works as well and lazily too.
The only weird part is getting a kotlin SourceDirectorySet from an
AndroidSourceSet
which uses reflection at the moment.