https://kotlinlang.org logo
Title
a

altavir

04/23/2019, 7:11 PM
@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

gildor

04/23/2019, 11:33 PM
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

altavir

04/24/2019, 6:30 AM
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

gildor

04/24/2019, 6:31 AM
build or configuration time?
a

altavir

04/24/2019, 6:31 AM
The build time.
g

gildor

04/24/2019, 6:32 AM
it’s really strange
what about parallelisation?
you can just do build scan by adding
--scan
to build command
a

altavir

04/24/2019, 6:32 AM
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

gildor

04/24/2019, 6:33 AM
there is also mpp parallelization
I would enable both, but it’s indifferent to problem with build time comparasion
a

altavir

04/24/2019, 6:34 AM
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

gildor

04/24/2019, 6:34 AM
10 minutes?
a

altavir

04/24/2019, 6:34 AM
yep
g

gildor

04/24/2019, 6:35 AM
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

altavir

04/24/2019, 6:38 AM
For normal build the numbers are similar. I will now try to switch to the buildSrc branch
g

gildor

04/24/2019, 6:40 AM
it’s about 10seconds for me now and very consistent
a

altavir

04/24/2019, 6:42 AM
OK, it seems to be working correctly now. Maybe it was some kind of gradle glitch...
g

gildor

04/24/2019, 6:43 AM
Sorry, not with
kotlin.incremental=true
, but with
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

altavir

04/24/2019, 6:48 AM
I think it is not the compilation, but the npm installation and package downlonad
Yesterday it was freezing on jvm compillation
g

gildor

04/24/2019, 6:49 AM
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

altavir

04/24/2019, 7:28 AM
I've merged config changes in dev. Gradle build seems to be working properly, but Idea integration is still unpredicatable.
g

gildor

04/24/2019, 7:32 AM
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
a

altavir

04/24/2019, 7:54 AM
Hmm... buildSrc does not seem to have access to project properties. Is there a way to fix that?
g

gildor

04/24/2019, 7:56 AM
which part of buildSrc?
a

altavir

04/24/2019, 7:56 AM
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

gildor

04/24/2019, 7:59 AM
hmm, should work, I will check
a

altavir

04/24/2019, 8:00 AM
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

gildor

04/24/2019, 8:00 AM
but you have access to project
a

altavir

04/24/2019, 8:00 AM
Is it my project or buildSrc root project?
g

gildor

04/24/2019, 8:01 AM
this is project where this plugin applied
it work for me
a

altavir

04/24/2019, 8:03 AM
I will try to debug it. Maybe problem lies elswhere
g

gildor

04/24/2019, 8:03 AM
Just tried this
put
artifactoryUser=someUser
to ~/.gradie/gradle.properties
a

altavir

04/24/2019, 8:04 AM
Yeah. I've just got the same idea
Yep. Now it works. I assumed it should merge properties files. Am I not correct?
g

gildor

04/24/2019, 8:05 AM
you also can pass gradle properties using
-PpropertyName=propertyValue
command line argument
yeah, project gradle.properties has higher priority
a

altavir

04/24/2019, 8:06 AM
Damn... the system is really archaic. I will move everything to user-level configutaion then.
g

gildor

04/24/2019, 8:07 AM
the system?
a

altavir

04/24/2019, 8:07 AM
gradle properties resolution
g

gildor

04/24/2019, 8:07 AM
why it is archaic?
you can put them to project level, just remove gradle.properties from git
or pass command line properties
a

altavir

04/24/2019, 8:09 AM
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

gildor

04/24/2019, 8:09 AM
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

altavir

04/24/2019, 8:10 AM
OK. I thought it should.
I do not see user-level properties then
g

gildor

04/24/2019, 8:11 AM
If you add property to
~/.gradle/gradle.properties
is doesn’t work for you?
a

altavir

04/24/2019, 8:11 AM
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

gildor

04/24/2019, 8:13 AM
you had properties in
~/gradle.properties
and this worked?
a

altavir

04/24/2019, 8:13 AM
yes
g

gildor

04/24/2019, 8:13 AM
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

altavir

04/24/2019, 8:18 AM
Yeah, I see that it should not be working, but it did...
g

gildor

04/29/2019, 1:57 AM
@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

altavir

04/29/2019, 4:28 AM
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

gildor

04/29/2019, 4:47 AM
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:
"jvmMainApi"("com.kyonifer:koma-core-api-jvm:0.12")
But ti also possible to get instance of configuration:
dependencies {
   val jvmMainApi by configurations
   jvmMainApi("com.kyonifer:koma-core-api-jvm:0.12")
}
a

altavir

04/29/2019, 4:58 AM
Are those configurations pre-generated by gradle plugin or are they generated on flight by name?
g

gildor

04/29/2019, 5:04 AM
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:
configurations["jvmMainApi"] ?: error("Configuration not found")
And doesn’t provide real type safety
a

altavir

04/29/2019, 5:07 AM
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

gildor

04/29/2019, 5:10 AM
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