moko-resources
moko-resources copied to clipboard
MR has no actual declaration in test for Native
When running native tests e.g. iosX64Test
we are getting the error
Expected object 'MR' has no actual declaration in module <com....:core-data_test> for Native
where core-data
is the name of the module containing common tests
I encountered a similar issue Expected object 'MR' has no actual declaration in module <shared_debug> for JVM
Same for me
Expected object 'MR' has no actual declaration in module <module_name:site> for JS
As mentioned in other issues with the same problem add dependsOn(commonMain) to androidMain in the build.gradle file.
val androidMain by getting {
dependsOn(commonMain)
dependencies {
...
}
}
As mentioned in other issues with the same problem add dependsOn(commonMain) to androidMain in the build.gradle file.
val androidMain by getting { dependsOn(commonMain) dependencies { ... } }
How would this be in the build.gradle.kts version?
@SimonJackler adding
val androidMain by getting {
dependsOn(commonMain)
dependencies {
...
}
}
cuases other weird issues!
it cannot find actual val
s for iosMain
and forces me to add actual
for all
iosX64, iosArm64, iosSimulatorArm64
any idea?
Adding the following resolves the issue but it looks ugly!
val androidMain by getting {
dependsOn(commonMain.get())
}
val iosMain by getting {
dependsOn(commonMain.get())
}
val iosArm64Main by getting {
dependsOn(iosMain)
}
val iosSimulatorArm64Main by getting {
dependsOn(iosMain)
}
val iosX64Main by getting {
dependsOn(iosMain)
}
Thanks
@bidadh Thats the way it works for me too. Ugly or not, it works :)
val iosX64Main by getting
val iosArm64Main by getting
val iosSimulatorArm64Main by getting
val iosMain by creating {
dependsOn(commonMain)
iosX64Main.dependsOn(this)
iosArm64Main.dependsOn(this)
iosSimulatorArm64Main.dependsOn(this)
dependencies {
...
}
}
@SimonJackler yes. we used to do this with the older versions of compose multiplatform plugin
but with the latest version it's much cleaner in terms of the gradle modules / builds
this is sort of one step back! haha.
but as you said, it works and it's good
Adding targetHierarchy.default()
in the kotlin {}
block solved the issue for me.
Reference
@OptIn(org.jetbrains.kotlin.gradle.ExperimentalKotlinGradlePluginApi::class)
kotlin {
targetHierarchy.default()
androidTarget {
compilations.all {
kotlinOptions {
jvmTarget = "1.8"
}
}
}
iosX64()
iosArm64()
iosSimulatorArm64()
// .......
}
Adding targetHierarchy.default() in the kotlin {} block solved the issue for me.
That call is no deprecated and replaced with applyDefaultHierarchyTemplate()
, but it has no effect on the issue for me