Hi, I try to see if a more approachable

build.gradle.kts

syntax is possible. My biggest source of frustration https://github.com/gradle/gradle/issues/9268 seems to move forward, so that's good news. When using multiplatform projects, the other one I have hard time with is when there is this kind of code which is I think the idiomatic one documented:

sourceSets {
    val commonMain by getting {
        dependencies {
            ...
        }
    }
}

Because: •

commonMain

is marked as never used in the IDE, how is it technically taken in account? • No discoverablity via autocomplete • I understand the technical reasons for

val commonMain by getting

but continues to looks to bit weird to me and not super approachable for beginners • It seems possible to write a much nicer version but I think it works only for

commonMain

not for platform specific variants:

sourceSets {
    commonMain {
        dependencies {
            ...
        }
    }
}

• Using

val commonMain

when there is the

commonMain

getter mentioned above is confusing I can understand that Kotlin team don't want to pollute the DSL with all the crazy native platforms supported, but I am wondering if middle term it could be possible to just write:

sourceSets {
    commonMain {
        dependencies {
            ...
        }
    }
    jvmMain {
        dependencies {
            ...
        }
    }
}

Not sure how, maybe by generating the right extensions based on the target configured on the project via a 2 passes approaches (not sure if that's possible)? Any thoughts? cc @eskatos

I just do

getByName("commonMain"){
      // stuff 
    }

This would help for nested containers https://github.com/gradle/gradle/issues/9264

That comment on the Github issue above is on point. Accessors alone is half of the problem, how would you handle registration?

Or create extensions yourself 😅

I guess

val commonMain by getting

is promoted because it looks like a bit more statically typed and leverage some Kotlin magic to get the name from the variable.

getByName("foo")

or

create("bar")

avoid the "never used issue" and looks a bit more familiar syntax, but does not seems the end game solution to me. Passing a string is not really statically typed API with autocomplete which is the promise of Gradle Jotlin DSL.

There is already some 2 passes analysis to read the plugins I think, couldn't targets be parsed as well and related extensions created?

plugins {}

works because it's a top level block and there are lots of constraints on it

Yep

For the Kotlin block I guess they could do the same but that would put even more constraints

^^

Think of everyone doing something like this for an example

afterEvaluate {
  kotlin {
    // bla
  }
}

Targets are standard, and if you don't generate the extensions, people can still use he regular ugly syntax.

The problem with source sets is that they are created after the Kotlin plugin has been applied:

kotlin {
  jvmMain() // jvmMain is created here
}

You mean:

kotlin {
  jvm()
}

?

Yup, edited

Yep, early approximative analysis via parsing is needed. here the goal is to create extensions for better syntax.

approximative analysis via parsing

FWIW (and AFAIK) this is not how it's done for plugins, it's actually calling

apply()

, running the code and reading the container values that have been contributed

it’s already possible to do

sourceSets.commonMain {}

in kts scripts

Yes that's mentioned in my original message

just in case, if you will create

jvm

target in some plugin (f.e. convention plugin) and apply it in your project, you will have autocomplete for

jvmMain

and

jvmTest

- the same will work for any other sourceSet created in this plugin (even custom, like

nativeMain

) f.e. jvm-convention.gradle.kts:

plugins {
  kotlin("multiplatform")
}
kotlin {
  jvm()
}

and in some module: build.gradle.kts:

plugins {
  id("jvm-convention")
}
kotlin {
  sourceSets {
    jvmMain { //will be generated type-safe accessor, even IDE will resolve it
    }
  }
}

Yes that’s mentioned in my original message

sorry I misunderstood!

Np

looks like the same machinery is working out of the box for

commonMain

as it’s created inside

kotlin-multiplatform

plugin

Interesting!

exactly what I was going to write Oleg :) There’s nothing special about

commonMain

vs

jvmMain

accessors.

kotlin.sourceSets

is a

NamedDomainObjectContainer

, and Gradle will generate Kotlin accessors for any named element so long as the elements are added before they are needed.

FYI instead of

getByName

and

create

you should use

named

and

register

respectively to avoid eager initialisation.

it’s also handy to register configurations in buildSrc convention plugins

// buildSrc/src/main/kotlin/some-convention.gradle.kts
val myConfiguration by configurations.registering { ...}

because then Gradle will generate an accessor

// build.gradle.kts
plugins {
  `some-convention`
}

dependencies {

As for accessors, commonMain works because it's created during plugin resolution time and jvmMain doesn't since it happens after that.

Maybe we just need specialization of:

plugins {
  kotlin("multilatform") version "1.8.0"
}

Like there is already:

ialization of:
plugins {
  kotlin("jvm") version "1.8.0"
}

For Wasm whihc was my use case, there could be maybe:

ialization of:
plugins {
  kotlin("wasm") version "1.8.0"
}

And that would create the related accesssors automaticalyy.

https://github.com/gradle/gradle/issues/9268 seems to move forward

Yeah, they work on a compiler plugin that makes it possible, hopefully they can finish that any time. 🙂

•

commonMain

is marked as never used in the IDE, how is it technically taken in account?

The

by

is Kotlin property delegate mechanism. While calculating the actual delegate to use, the delegate mechanism can access the property name. So the name is acutally used. If IJ shows it as unused, that's imho a bug in IJ. I personally prefer those delegates over the string variant Martin suggested for refactoring and reuse, if just IJ would not show them as unused.

No discoverablity via autocomplete

That's the same for all of these named domain object containers Accessors that can then be autocompleted like the

commonMain

if you use the

sourceSets

within

kotlin { ... }

are generated from applying the plugins in the

plugins { ... }

block to a dummy project and investigating which things were added.

commonMain

is always added, so an accessor can be generated.

jvmMain

for example is only added if

kotlin { jvm() }

is done, so on that dummy project is not present and so no accessor can be generated. That is the price for a type-safe DSL.

Targets are pretty standardized, could not be the end of te world to parse ...

The point is, that this 2-phase thing is done by Gradle uniformly no matter which plugins are applied, not by the Kotlin plugin. So having special handling for Kotlin targets would introduce Kotlin plugin specifics into the Gradle core and that would not be too clean designwise unless some pluggable approach is invented. I think I made a feature request for that quite some time ago, but do not find it right now.

You could get jvmMain accessor by invoking jvm() target inside buildSrc precompuled script plugin instead on the project directly

And yes, if you would have specialized versions of the plugin for the different targets, that would allow accessors to be generated.

+1 to convention plugin all the things

Great, thanks for all your feedback, super interesting.

AFAIK https://github.com/gradle/gradle/issues/9268 PREVIEW is ‘planned’ for 8.1

jvmMain

for example is only added if

kotlin { jvm() }

is done, so on that dummy project is not present and so no accessor can be generated. That is the price for a type-safe DSL.

So maybe we need a 3 passes analysis 😅

something else to consider, to help avoiding tonnes of fragmented source sets, is to create a hierarchical structure to group related sourceSets

sourceSets {
         val commonMain by getting {}
         val commonTest by getting {}

         val nativeMain by creating { dependsOn(commonMain) }
         val nativeTest by creating { dependsOn(commonTest) }

         // Linux
         val linuxX64Main by getting { dependsOn(nativeMain) }
         val linuxX64Test by getting { dependsOn(nativeTest) }

         // Windows - MinGW
         val mingwX64Main by getting { dependsOn(nativeMain) }
         val mingwX64Test by getting { dependsOn(nativeTest) }

   // and so on...

full code here:

build-logic/src/main/kotlin/ks3/conventions/lang/kotlin-multiplatform-native.gradle.kts

Hapefully Wasm will make things simpler there for me

regarding sourceSet/target hierarchies, soon (in 1.8.20) we will have experimental KGP API to define them in much more concise way: https://youtrack.jetbrains.com/issue/KT-53570/multiplatform-natural-hierarchy-prototype and it will work with convention plugins, so if you define hierarchy(default is single line, but custom hierarchies are possible) and targets(f.e. linux*, macos*, ios*, etc) in convention plugin - ALL sourceSet accessors like linuxMain/Test, macosMain/Test, appleMain/Test, nativeMain/Test will be generated and accessible from build script

So maybe we need a 3 passes analysis

You cannot make an automated 3 pass analysis. Gradle cannot know what exactly to copy over to the dummy project.

Yeah probably not a good idea.

Ah, that's the feature request I meant, but it was rejected: https://github.com/gradle/gradle/issues/16107