https://kotlinlang.org logo
Join Slack
Powered by
Can any gradle experts explain a behavior to me th...
# gradle
a
Can any gradle experts explain a behavior to me that I'm losing my mind about...? There is a behavior in gradle-KMP that is driving me nuts. When I do something like this:
Copy code
tasks.named("linkDebugTestLinuxX64") { stuff }
It blows up the build like so:
Copy code
An exception occurred applying plugin request [id: 'nativebuild']
> Failed to apply plugin 'nativebuild'.
   > Task with name 'linkDebugTestLinuxX64' not found in project ':terpal-sql-core'.
Yet when I do this:
Copy code
tasks.all {
  if (name.contains("linkDebugTestLinuxX64")) {
    println("--------------- Found: linkDebugTestLinuxX64")
    stuff
  }
}
It works just fine and I see the printout. What is going on here? Is Gradle mutating the build-tree between two different steps?
v
Of course, continuously during configuration phase
Using 
tasks.named("...")
only works if the task you want to get is already registered. If for example some plugin that is applied later registers the task or does it reactively the task is not yet present when you call that function.
tasks.all { ... }
on the other hand processes each and every registered task, no matter whether already registered or in the future, but you should never use it except for debugging, because it completely breaks task-configuration avoidance.
How to properly do "it" depends on what "it" would be.
a
I need to do the equivalent of this:
Copy code
tasks.named("linkDebugTestMingwX64") { enabled = HostManager.hostIsMingw }
v
Do you want to depend on that task? Do you want that task to depend on something? Do you want to configure that task? Do you want to ...?
tasks.named { it == "linkDebugTestMingwX64" }.configureEach { enabled = HostManager.hostIsMingw }
a
How is configureEach different?
v
From what?
a
How is it different from this:
Copy code
tasks.named("linkDebugTestMingwX64") { enabled = HostManager.hostIsMingw }
and from this:
Copy code
tasks.all {
  if (name.contains("linkDebugTestLinuxX64")) {
    enabled = HostManager.hostIsMingw
  }
}
v
different from the first: it works different from the second: it does not break task-configuration avoidance
You can also do 
tasks.configureEach { ... }
and check the name therein, that would probably not make too much difference
a
Can you explain a bit more about what task-configuration avoidance is?
Is that a term I can search?
v
Yes
a
Ah, so its a lazy-vs eager thing
v
Kind of
But not only lazy, but super lazy. Not doing any work for task that are not going to be realized anyway.
a
What confuses me is that in the gradle-DSL the command
Copy code
tasks.named("linkDebugTestLinuxX64") { enabled = HostManager.hostIsLinux }
works just fine. Is the gradle-DSL "lazier" that the Kotlin one?
v
What do you mean when you say "the gradle-DSL"?
a
I see this command used in build.gradle vs build.gradle.kts and it doesn't produce the same error I'm seeing
v
ah, so you mean Groovy DSL
Because both are Gradle DSL
No, Groovy DSL behaves the same in that part
There are things that work differently due to legacy and backwards compatibility reasons, but that works the same
If it behaves differently, then because you did something else differently that causes that task to already be registered at the point you are calling that method
a
Interesting! Thanks for the details
👌 2
2 Views
Open in Slack
PreviousNext
Powered by