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

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

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.

build or configuration time?

The build time.

it’s really strange

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.

there is also mpp parallelization

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.

10 minutes?

yep

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

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

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

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

Sorry, not with

kotlin.incremental=true

, but with

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

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

no, this build is with installed npm and modules

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

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

Hmm... buildSrc does not seem to have access to project properties. Is there a way to fix that?

which part of buildSrc?

The artifactory plugin takes configuration from properties like

val artifactoryUser: String? by project

. It seems to return null

hmm, should work, I will check

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)

but you have access to project

Is it my project or buildSrc root project?

this is project where this plugin applied

I will try to debug it. Maybe problem lies elswhere

Just tried this

Yeah. I've just got the same idea

you also can pass gradle properties using

-PpropertyName=propertyValue

command line argument

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

the system?

gradle properties resolution

why it is archaic?

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

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

OK. I thought it should.

If you add property to

~/.gradle/gradle.properties

is doesn’t work for you?

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

you had properties in

~/gradle.properties

and this worked?

yes

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

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

@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

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.

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

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

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*

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.

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