One more question on `org.jetbrains.kotlin.multipl...

# multiplatform

[r4zzz4k]

One more question on `org.jetbrains.kotlin.multiplatform`:
Do I understand correctly that *Test source sets have some specific kind of dependency on *Main, not simple dependsOn?
I'm trying to add testFixtures source set as follows:

commonMain { ... }
commonTestFixtures { dependsOn commonMain }
commonTest { dependsOn commonTestFixtures }

nativeMain { ... }
nativeTestFixtures { dependsOn nativeMain }
nativeTest { dependsOn nativeTestFixtures }

I'm getting internal compiler errors, and after commenting out types mentioned in them just for the sake of moving forward on build process, I got the following from linker:
llvm-lto: error: Linking globals named 'ktype:org.sample.InterfaceName': symbol multiply defined!
Apart from the error itself compiler reports source file names, where I clearly see duplications -- but I'm not sure if they are from common / platform modules or duplicated platform module.

I guess I'm doing this wrong, but I'm not sure how to redo it properly -- testFixtures definitely needs access to main as it is based on some types from there, and the sole purpose of it is to provide utilities for test source set.

[h0tk3y]

Yes, indeed, the connection between production and tests code is not modelled with the `KotlinSourceSet`'s dependsOn relation. Instead, we model it by means of `KotlinCompilation`s, where we setup the test compilation to consume the compiled classes (in contrast with the sources) of the production compilation. You could basically do the same for your platform-specific testsl source sets by adding the production compilation's outputs of the same target to the test source set dependencies. This will also build common test sources participating in the test compilations, but the IDE import won't handle shared test sources well, because IDE import relies on the source sets model to a greater degree. Platform-agnostic test source sets are hard to model in existing terms, we might need some additional design to cover this.

[r4zzz4k]

Thanks! I'm afraid that my Gradle knowledge won't be enough for that, as I bet it's done differently for JVM and Native, for example.
I've decided to take a bit simpler route, by separating fixtutres and tests into separate Gradle modules to be able to take usual dependencies route.
I'm not sure if there is a way to specify exact sourceSet to depend onto, or maybe get library artifact -- will continue this tomorrow.