Simon Marquis
09/29/2023, 12:18 PM// settings.gradle.kts
pluginManagement {
includeBuild("build-logic")
}
When running a classic build, a new Kotlin Compiler daemon is spawn to compile the build-logic
Kotlin classes, as expected.
But when Gradle moves to the actual project compilation, a new Kotlin Compiler daemon is spawn again, and the previous one is not reused, nor killed. This is unexpected to me.
By looking at the JVM arguments and system properties of both daemons (with VisualVM), they are almost identical.
The only difference is on java.class.path/sun.java.command
where on one hand it references Kotlin jars in version 1.9.0
versus 1.9.10
on the other.
Is this the reason why the daemon is not reused? And if yes, how can this be changed?
By looking at these docs:
Avoid specifying a version for theAnd the corresponding changelogs seems empty. So I'm not sure what to do about this, and would love to get some help 🙂pluginkotlin-dsl
Vampire
09/29/2023, 12:42 PMSimon Marquis
09/29/2023, 1:39 PMkotlin-dsl
to 4.1.2 made the daemon reused and does not seem to introduce any regression 👍Vampire
09/29/2023, 1:40 PMSimon Marquis
09/29/2023, 1:40 PMVampire
09/29/2023, 1:44 PMSimon Marquis
09/29/2023, 1:46 PMVampire
09/29/2023, 1:48 PMSimon Marquis
09/29/2023, 1:56 PMbuild-logic
) which is requested by kotlin-dsl
plugin (1.9.0 in this case)
• the main build (aka, all by gradle.kts
files of all my other modules) which comes from the root build.gradle.kts
(1.9.10 in this case)
plugins {
alias(libs.plugins.kotlin.jvm) apply false
}
• the app source code (aka kotlin-stdlib*
) which comes from the applied plugin
Or are these last two items always identical?Vampire
09/29/2023, 1:58 PMSimon Marquis
09/29/2023, 1:59 PMVampire
09/29/2023, 2:01 PMbuild-logic
uses 1.9.0 as defined through kotlin-dsl
.
Executing the build scripts of the main build uses 1.9.0 as defined through Gradle.
The 1.9.10 plugin you apply makes your production classes compiled with 1.9.10.Simon Marquis
09/29/2023, 2:03 PMExecuting the build scripts of the main build uses 1.9.0 as defined through Gradle.I think this is the part that I don't get 😅
Vampire
09/29/2023, 2:08 PMSimon Marquis
09/29/2023, 2:11 PMVampire
09/29/2023, 2:13 PMSimon Marquis
09/29/2023, 2:21 PMhfhbd
09/29/2023, 2:41 PMVampire
09/29/2023, 2:49 PMmy main goal was to avoid having 2 daemonsWell, for that you have to align the versions and thus downgrade your production Kotlin version to 1.9.0, or use Gradle 8.4, yes. But imho you really shouldn't couple these versions.
Simon Marquis
09/29/2023, 3:12 PMbuild-logic
into a dedicated project, and publish it somewhere to not have to compile it from the main project?
Another one that I'm thinking about is, would it be possible to override some kind of Kotlin daemon timeout (time after which it is killed if unused)? Because at the moment, it is kept alive for at least the whole duration of the build, and hangs onto ~1 to 2g of RAM. --no-daemon
does not seem to affect it, and gradle.properties
inside the build-logic
are ignored 🤷Vampire
09/29/2023, 3:37 PM--no-daemon
is just about the Gradle build daemon, could well be that the Kotlin compile deamon survives that.Simon Marquis
09/29/2023, 3:50 PM--daemon-autoshutdownIdleSeconds=7200
given as argument to the Kotlin Compile Daemon.
But this is probably not configurable (at the moment) https://youtrack.jetbrains.com/issue/KT-50510/Gradle-Add-the-possibility-to-change-daemon-autoshutdownIdleSeconds
Anyway, thanks a lot for all these informations 🙏Alexander.Likhachev
10/01/2023, 11:02 PMVampire
10/01/2023, 11:03 PMAlexander.Likhachev
10/01/2023, 11:05 PMSimon Marquis
10/02/2023, 2:04 PMAlexander.Likhachev
10/02/2023, 6:23 PMbuildSrc
or the single build-logic
module. It shouldn’t cause any problems in this case if you’re ok with not having incremental compilation for that module.Simon Marquis
10/02/2023, 6:30 PM