Does anyone know if it's possible to make an `inte...

# multiplatform

[simon.vergauwen]

Does anyone know if it's possible to make an integrationTest sourceSet but for KMP? I tried doing it (for JVM target only, but KMP would be even better) but the code (attached in thread) seems to break the commonMain & commonTest sourceSets.. It's in a private project, but I can recreate a reproducible for YouTrack if this is a bug.

[simon.vergauwen]

Untitled.kt

Untitled.kt

[ephemient]

sure it is possible, just create an additional compilation on each target you want it on

[ephemient]

I have a public project which has kotlin { jvm { compilations.create("bench") }; sourceSets { getByName("jvmBench").dependsOn(getByName("jvmMain")) } } just fine: https://github.com/ephemient/aoc2022/blob/main/kt/build.gradle.kts

[ephemient]

you might have to clarify what issue you're running into

[Sebastian Sellmair [JB]]

Please do not use ‘benchmark’.dependsOn(main). Use .associateWith instead!

[ephemient]

I haven't touched that in a while, but IIRC associateWith resulted in duplicate class definitions

[Sebastian Sellmair [JB]]

If this would still be the case, please file a bug!
Probably interesting for @atyrin here.

A dependsOn from one ‘SourceSetTree’ to another ‘SourceSetTree’ will be deprecated in 1.9.20 and removed in Kotlin 2.0

[Sebastian Sellmair [JB]]

Here is documentation of what I mean by ‘SourceSetTree’
https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-gradle-plug[…]lin/org/jetbrains/kotlin/gradle/plugin/KotlinTargetHierarchy.kt

TL;DR:
main and test are trees
commonMain, jvmMain, … are part of the ‘main’ tree
commonTest, jvmTest, … are part of the ‘test’ tree
commonBenchmark, jvmBenchmark, … would be part of the ‘benchmark’ tree

[Sebastian Sellmair [JB]]

If you would like to get the internals from test <-> main, then associateWith shall be used (is also used for our default test compilations that we create for you)
If one tree should be able to see the internals of another tree, then `assocaite

[ephemient]

I work on aoc every december so when I revisit it this year, 1.9 should be out and I'll check that the new way works

[Sebastian Sellmair [JB]]

😎 Deal! We will likely check as well when we deprecate the depends relation in this manner.

[simon.vergauwen]

Okay, associateWith fixed it 🥳 Thank you.
@Sebastian Sellmair [JB], does this look correct to you?

jvm {
  compilations {
    val integrationTest by compilations.creating {
      // Create a test task to run the tests produced by this compilation:
      tasks.register<Test>("integrationTest") {
        description = "Run the integration tests"
        group = "verification"
        classpath = compileDependencyFiles + runtimeDependencyFiles + output.allOutputs
        testClassesDirs = output.classesDirs

        testLogging {
          events("passed")
        }
      }
    }
    val test by compilations.getting
    integrationTest.associateWith(test)
  }
}

Btw can I still use dependsOn for creating a common native sourceSet 🤔?

create("nativeMain") {
  dependsOn(commonMain)
  linuxX64Main.dependsOn(this)
  macosX64Main.dependsOn(this)
  mingwX64Main.dependsOn(this)
}

[Sebastian Sellmair [JB]]

Your code looks perfectly correct 👍
Yes you still can use dependsOn for exactly this use case. However, even this usage will be marked as DelicateKotlinGradlePluginApi and shall be replaced by targetHierarchy.default() , targetHierarchy.custom or similar.

Also interesting: We plan that 1.9.20 will automatically create source sets like nativeMain for you 👍

[simon.vergauwen]

Awesome, thank you so much for replying and clarifying my doubt @Sebastian Sellmair [JB]

[Marco Righini]

@Sebastian Sellmair [JB] Currently having issues setting up the custom compilation for an ios target (snippet above). Compilation and linking are executed but no tests are run with iosSimulatorArm64IntegrationTest
Tests are correctly defined in commonIntegrationTest

[Marco Righini]

Untitled

Untitled