<@U0BRK9HC5> I am moving discussion to appropriate channel. I've applied your patches, and it seems ...

# gradle

[altavir]

@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.

[gildor]

Did you try to compare build scans for old and new configs?

[gildor]

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

[altavir]

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.

[gildor]

build or configuration time?

[altavir]

The build time.

[gildor]

it’s really strange

[gildor]

what about parallelisation?

[gildor]

you can just do build scan by adding --scan to build command

[altavir]

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.

[gildor]

there is also mpp parallelization

[gildor]

I would enable both, but it’s indifferent to problem with build time comparasion

[altavir]

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.

[gildor]

10 minutes?

[altavir]

yep

[gildor]

With parallelization 25 seconds for me including tests
./gradlew check --no-build-cache

[gildor]

BUILD SUCCESSFUL in 25s

[gildor]

15 seconds with
kotlin.parallel.tasks.in.project=true
kotlin.incremental=true

[altavir]

For normal build the numbers are similar. I will now try to switch to the buildSrc branch

[gildor]

it’s about 10seconds for me now and very consistent

[altavir]

OK, it seems to be working correctly now. Maybe it was some kind of gradle glitch...

[gildor]

Sorry, not with kotlin.incremental=true, but with

kotlin.parallel.tasks.in.project=true
org.gradle.parallel=true

[gildor]

This is check task without build cache after clean
https://scans.gradle.com/s/sumxx2aisyflu

[gildor]

Looks that JS compilation is slowest part

[altavir]

I think it is not the compilation, but the npm installation and package downlonad

[altavir]

Yesterday it was freezing on jvm compillation

[gildor]

no, this build is with installed npm and modules

[gildor]

and this JS compilation
See
https://scans.gradle.com/s/sumxx2aisyflu/timeline?sort=duration

[gildor]

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

[altavir]

I've merged config changes in dev. Gradle build seems to be working properly, but Idea integration is still unpredicatable.

[gildor]

Yeah, sometimes it’s not so smooth, but you already kotlin dsl 😁

[gildor]

actually it make sense to report all those issues with Kotlin DSL tooling to Kotlin issue tracker

[gildor]

usually after proper sync tooling is fine for me, biggest pain point is when you add some new plugin/script

[gildor]

which part of buildSrc?

[altavir]

The artifactory plugin takes configuration from properties like val artifactoryUser: String? by project. It seems to return null

[altavir]

gradle.properties file is in the system user directory

[gildor]

hmm, should work, I will check

[altavir]

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)

[gildor]

but you have access to project

[altavir]

Is it my project or buildSrc root project?

[gildor]

this is project where this plugin applied

[gildor]

it work for me

[altavir]

I will try to debug it. Maybe problem lies elswhere

[gildor]

Just tried this

[gildor]

put artifactoryUser=someUser to ~/.gradie/gradle.properties

[altavir]

Yeah. I've just got the same idea

[altavir]

Yep. Now it works. I assumed it should merge properties files. Am I not correct?

[gildor]

you also can pass gradle properties using -PpropertyName=propertyValue command line argument

[gildor]

yeah, project gradle.properties has higher priority

[altavir]

Damn... the system is really archaic. I will move everything to user-level configutaion then.

[gildor]

the system?

[altavir]

gradle properties resolution

[gildor]

why it is archaic?

[gildor]

you can put them to project level, just remove gradle.properties from git

[gildor]

or pass command line properties

[altavir]

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

[gildor]

one more thing, now to enable js test you use project extensions, not properties, I just keep old behavior there

[gildor]

But it merges proprties

[gildor]

Maybe I misunderstood your question

[altavir]

OK. I thought it should.

[altavir]

I do not see user-level properties then

[gildor]

If you add property to ~/.gradle/gradle.properties is doesn’t work for you?

[altavir]

maybe something changed in gradle default placement for user properties...

[altavir]

ah... a moment

[altavir]

Yes, now I can see it. Before it was working fine from user home directory

[altavir]

thanks for the help

[gildor]

you had properties in ~/gradle.properties and this worked?

[altavir]

yes

[gildor]

interesting, maybe they removed support of this between 5.0 and 5.4, but it’s a breaking change, so don’t think so

[gildor]

https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties

[altavir]

Yeah, I see that it should not be working, but it did...

[gildor]

@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

[altavir]

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.

[gildor]

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")
}

[altavir]

Are those configurations pre-generated by gradle plugin or are they generated on flight by name?

[gildor]

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*

[gildor]

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

[gildor]

This syntax:
val jvmMainApi by configurations

is just syntactic sugar for:

configurations["jvmMainApi"] ?: error("Configuration not found")

And doesn’t provide real type safety

[altavir]

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.

[gildor]

Type safe accessors are not something very new, it available from some pre-1.0 RCs

[gildor]

And this thing that really improves type-safety of configs and provides code completion

[gildor]

were several bad design decisions since then

What exactly do you mean?

[gildor]

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