https://kotlinlang.org logo
Join Slack
Powered by
<@U0BRK9HC5> I am moving discussion to appropriate...
# gradle
a
@gildor I am moving discussion to appropriate channel. I've applied your patches, and it seems to be working, but the build speed dropped dramatically. If I won't find a way to fix it, I will have to move back to one-file configuration.
g
Did you try to compare build scans for old and new configs?
I checked clean builds and incremental build scans, looks fine for me. Kotlin DSL is slower on first run, requires more accessors generation and compilation, but it shouldn’t than affect build time, only configuration But of course it may be some bug for sure
a
The build time is significantly slower. I've separated new build logic into a separate branch and reverted dev to old setup. I will try build scan later. I do not have any experience with it.
g
build or configuration time?
a
The build time.
g
it’s really strange
what about parallelisation?
you can just do build scan by adding 
--scan
to build command
a
I am not sure. As far as I remember, parallelization is off by default for kotlin builds. So it should be the same in both cases.
g
there is also mpp parallelization
I would enable both, but it’s indifferent to problem with build time comparasion
a
The fact is that in old setup clean build takes about minute and in new setup, I've waited for about 10 minutes and had to cancel it. It was moving forward, but very slowly.
g
10 minutes?
a
yep
g
With parallelization 25 seconds for me including tests ./gradlew check --no-build-cache
BUILD SUCCESSFUL in 25s
15 seconds with kotlin.parallel.tasks.in.project=true kotlin.incremental=true
a
For normal build the numbers are similar. I will now try to switch to the buildSrc branch
g
it’s about 10seconds for me now and very consistent
a
OK, it seems to be working correctly now. Maybe it was some kind of gradle glitch...
g
Sorry, not with 
kotlin.incremental=true
, but with
Copy code
kotlin.parallel.tasks.in.project=true
org.gradle.parallel=true
This is 
check
task without build cache after 
clean
https://scans.gradle.com/s/sumxx2aisyflu
Looks that JS compilation is slowest part
a
I think it is not the compilation, but the npm installation and package downlonad
Yesterday it was freezing on jvm compillation
g
no, this build is with installed npm and modules
also build resolves dependnencies on configuration time, this is some problem of build config or some plugin, can check later, but you have not so many dependencies, it’s just about 84ms per build
a
I've merged config changes in dev. Gradle build seems to be working properly, but Idea integration is still unpredicatable.
g
Yeah, sometimes it’s not so smooth, but you already kotlin dsl 😁
actually it make sense to report all those issues with Kotlin DSL tooling to Kotlin issue tracker
usually after proper sync tooling is fine for me, biggest pain point is when you add some new plugin/script
which part of buildSrc?
a
The artifactory plugin takes configuration from properties like 
val artifactoryUser: String? by project
. It seems to return null
gradle.properties
file is in the system user directory
g
hmm, should work, I will check
a
Maybe something went wrong in onther places. But I've googled a bit and it seems like plugins in buildsrc do not have direct access to properties (If I understand correctly)
g
but you have access to project
a
Is it my project or buildSrc root project?
g
this is project where this plugin applied
it work for me
a
I will try to debug it. Maybe problem lies elswhere
g
Just tried this
put 
artifactoryUser=someUser
to ~/.gradie/gradle.properties
a
Yeah. I've just got the same idea
Yep. Now it works. I assumed it should merge properties files. Am I not correct?
g
you also can pass gradle properties using 
-PpropertyName=propertyValue
command line argument
yeah, project gradle.properties has higher priority
a
Damn... the system is really archaic. I will move everything to user-level configutaion then.
g
the system?
a
gradle properties resolution
g
why it is archaic?
you can put them to project level, just remove gradle.properties from git
or pass command line properties
a
Because, the merge is obvious solution. Yet, I am getting ahead of myself. I moved everything to user config, and it could not be seen from the project
g
one more thing, now to enable js test you use project extensions, not properties, I just keep old behavior there
But it merges proprties
Maybe I misunderstood your question
a
OK. I thought it should.
I do not see user-level properties then
g
If you add property to 
~/.gradle/gradle.properties
is doesn’t work for you?
a
maybe something changed in gradle default placement for user properties...
ah... a moment
Yes, now I can see it. Before it was working fine from user home directory
thanks for the help
g
you had properties in 
~/gradle.properties
and this worked?
a
yes
g
interesting, maybe they removed support of this between 5.0 and 5.4, but it’s a breaking change, so don’t think so
a
Yeah, I see that it should not be working, but it did...
g
@altavir Hey, just discovered that because we use custom plugin for configuration, we actually can use type-safe accessors for configuration, so it’s possible to use 
dependencies
block instead of sourceSet DSL: https://github.com/mipt-npm/kmath/compare/dev...gildor:type-safe-configuration?expand=1 Just interested about your opinion, how do you think is it make sense, I like it because it less typing, less nesting and uses standard Gradle dependencies DSL
a
I am not sure it is significantly better. On one hand it is shorter, on the other, it is harder to move from one project to another and there are already some bizarre errors appearing when using different configurations (like mixing 
compile
with 
api
). I think this notation would be useful, but only if it is more universal.
g
harder to move from one project to another
Do you mean to completely different project? You have those configurations even without custom plugin, but no type-safe accessors:
Copy code
"jvmMainApi"("com.kyonifer:koma-core-api-jvm:0.12")
But ti also possible to get instance of configuration:
Copy code
dependencies {
   val jvmMainApi by configurations
   jvmMainApi("com.kyonifer:koma-core-api-jvm:0.12")
}
a
Are those configurations pre-generated by gradle plugin or are they generated on flight by name?
g
This is how Kotlin DSL works. It generates type-safe accessors for configurations (and tasks, extensions etc) that are created on configuration time (when plugin applied using 
plugins{}
block) Because those configurations are created on runtime when you create new target of MPP plugin, like 
js {}
or 
jvm("java8") {}
so you have no type safe accessors for them, only for 
commonMain*
and 
commonTest*
But because in this case we configure js and jvm targets in separate plugin and apply it using 
plugins{}
dsl, Gradle allows us to use type-safe accessors for configuraions available after configuration time, so if you try to use for example 
iosArm64MainApi
you will get error, until you add 
iosArm64{}
target to 
multiplatform-config
This syntax: 
val jvmMainApi by configurations
is just syntactic sugar for:
Copy code
configurations["jvmMainApi"] ?: error("Configuration not found")
And doesn’t provide real type safety
a
OK. It looks good. I am a bit cautious about gradle innovations. I do not have a good understanding of its workings anymore. I remember, I was quite excited when it appeared, but I believe there were several bad design decisions since then.
g
Type safe accessors are not something very new, it available from some pre-1.0 RCs
And this thing that really improves type-safety of configs and provides code completion
were several bad design decisions since then
What exactly do you mean?
I agree, for example too many ways to configure tasks is may be quite confusing, but in general I like what they did in last updates, it removed a lot of boilerplate and improved usability
3 Views
Open in Slack
PreviousNext
Powered by