https://kotlinlang.org logo
Title
s

simon.vergauwen

05/08/2023, 2:03 PM
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.
Untitled.kt
e

ephemient

05/08/2023, 3:32 PM
sure it is possible, just create an additional compilation on each target you want it on
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
you might have to clarify what issue you're running into
s

Sebastian Sellmair [JB]

05/08/2023, 3:58 PM
Please do not use ‘benchmark’.dependsOn(main). Use .associateWith instead!
e

ephemient

05/08/2023, 3:59 PM
I haven't touched that in a while, but IIRC
associateWith
resulted in duplicate class definitions
s

Sebastian Sellmair [JB]

05/08/2023, 4:00 PM
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
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
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
e

ephemient

05/08/2023, 4:04 PM
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
s

Sebastian Sellmair [JB]

05/08/2023, 4:05 PM
😎 Deal! We will likely check as well when we deprecate the depends relation in this manner.
s

simon.vergauwen

05/08/2023, 4:32 PM
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)
}
s

Sebastian Sellmair [JB]

05/09/2023, 7:26 AM
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 👍
s

simon.vergauwen

05/09/2023, 7:27 AM
Awesome, thank you so much for replying and clarifying my doubt @Sebastian Sellmair [JB]