https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
r

r4zzz4k

09/17/2018, 11:41 AM
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:
Copy code
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.
h

h0tk3y

09/17/2018, 2:28 PM
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.
r

r4zzz4k

09/17/2018, 7:05 PM
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.
6 Views