This message was deleted.
# kotlin-dsl
s
This message was deleted.
e
kotlin-dsl already applies a plugin, see https://github.com/gradle/gradle/blob/master/subprojects/kotlin-dsl-plugins/src/main/kotlin/org/gradle/kotlin/dsl/plugins/dsl/KotlinDslCompilerPlugins.kt any other custom compiler plugin added there would also be applied to script and binary plugins too
👍 1
j
I think the experience could be great with kts if, for example, at same time you add a plugin to the plugin block, the file already has the accessors instead of forcing to resync. Currently the implementation for me is similar to Dagger, you can put "red code" which is correct and you need to compile in order to know that it is going to be generated, but with the Kotlin DSL you are experience this issue in every build file, with Dagger only in a few files or none (with Hilt for example). Moving to an implementation that depends on the frontend for the accessors would improve the experience a lot because you can generate accessors and get autocompletion for scripts that are unable to sync
a
Interesting idea. Maybe main issue here is, that
build.gradle.kts
is compiled in two passes: first the plugins block (so you can get actual dependencies of a script) and only then the other parts. So I would guess this to function would require something more than just a Kotlin compiler plugin.
e
and in between the two steps there's Gradle's dependency resolution. I think chances are low that can be moved into a compiler plugin, especially since it can involve executing configuration from build/settings scripts and plugins, so you'd have to come up with some kotlinc/Gradle daemon communication? the more I think about it the hairier it seems
j
Is it possible to fail in the second step with the autocomplete being working? I understand that if the first step fail Gradle shouldn’t be able to fix the autocomplete feature because there is no way to know what sources are available. But if that step works, even if the sync fails, the autocomplete should be working. Is it possible that the codegen would be done before step 2 and allow the autocomplete to work with that second step failing?
a
That codegen before step 2 could work yes. But from a top of my head, I don’t know in details what would need to change: would we need just some Gradle change or we would need to also change how IDE queries build script dependencies? Not sure.
🤔 1