https://kotlinlang.org
Join Slack
Happy New Year! After updating Kotlin to 1.3.61, I have the a problem with iOS. I get `unresolved r...
# multiplatform
c
Happy New Year! After updating Kotlin to 1.3.61, I have the a problem with iOS. I get 
unresolved reference: platform
on Android Studio in my 
iosMain
files, unless I add this:
Copy code
iosX64Main {
    …
    kotlin.srcDirs += project.file("src/iosMain/kotlin")
}
iosArm64Main {
    …
    kotlin.srcDirs += project.file("src/iosMain/kotlin")
}
(I can generate the library though, so it seems the problem is with Android Studio) But if I add that, then it starts expecting new actuals: 
expected class 'X' has no actual declaration in module my-app_iosX64Main for Native
k
c
After reading that, it seems I fixed it by only adding 
iosX64('ios')
👍 1
I don’t understand why I should do that though, it isn’t what the documentation seems to imply. It says that 
ios
should be creating 
targets for iosArm64 and iosX64
and that I should create 
an intermediate source set (iosMain) and configuring links between it and the platform source sets
. While here it seems I’m changing the name of the 
iosX64
target to 
ios
and using that as a base to build 
iosArm64
, which sounds wrong… as I have different dependencies for both targets
e
Assuming you have a source set named "ios" and want to share it between different iOS targets, each of the specific source sets (is. iosArm64, iosX86) needs to depend on the common one. You can use "dependsOn" to accomplish that.
c
@Erik Christensen I am doing that already, I had this working before updating Kotlin
k
you should do that to workaround a limitation in IDEA
you're accommodating the IDE
c
ah OK, that makes more sense
k
JB is working on the issue, hopefully it will be cleaned up in 1.4
🤞
c
cool 👍
will changing the name of 
iosX64
to 
ios
not mess up my dependencies? I have most dependencies on 
iosMain
, but then 
iosX64Main
and 
iosArm64Main
(each 
dependsOn
iosMain
) add some extra architecture-specific dependencies
e
To make the IDE happy for now, you can check for a Gradle property that indicates that IDEA is active and setup your targets so as to avoid having a shared source set just in that context. This is done in kotlinx coroutines and I'm also using that trick in Island Time.
c
basically, my question is: does the meaning of 
iosMain
change if I rename 
iosX64
to 
ios
?
e
iosMain
becomes the target's source set rather than a shared source set between targets when you do that
c
mmm… that’s what I feared, that doesn’t sound good, I could use that line to fix the IDE problems while I’m developing and then remove it when generating the .framework
you can check for a Gradle property that indicates that IDEA is active and setup your targets so as to avoid having a shared source set just in that context
How do you do that? where can I read more about it?
e
I'm doing the multiplatform setup in buildSrc -- see multiplatform-library.gradle.kts
c
found it already 😉
will 
ideaActive
be true if I launch a gradle task from Android Studio?
or only when the IDE itself uses it behind the scenes?
e
It seems to be true whenever Gradle is invoked by the IDE, but not when I run it from a command line outside the IDE
c
mmm, so it’s still a little bit dangerous
until we stop double clicking on the gradle task at least 😛
thank you both @Kris Wong and @Erik Christensen 👍
e
It's a hack for sure, but the alternatives right now seem to be manually modifying the Gradle scripts every time or using symlinks to share the common source set and those approaches have worse drawbacks IMO 🙂
c
My fix:
Copy code
// You may uncomment this line for autocompletion to work on Android Studio
//iosX64('ios') // DO NOT COMMIT THIS UNCOMMENTED LINE
😅
k
why?
what issue do you perceive with having 
iosMain
as the target's source set?
c
@Kris Wong as I said above:
I have most dependencies on iosMain, but then iosX64Main and iosArm64Main (each dependsOn iosMain) add some extra architecture-specific dependencies
So if Erik’s statement is true:
iosMain becomes the target’s source set rather than a shared source set between targets when you do that
That would mean that iosArm64 could contain iosX64 specific code
I haven’t tested it yet though, I’ll eventually do it to be sure
If it’s true, it probably works for you anyway if you don’t have architecture specific dependencies.
If it’s not true, then something more magical is going on… I’m sick of all this implicit behavior, I really hate “convention over configuration” :P
k
I have also solved this problem of target specific dependencies
let me paste an example
Copy code
iosX64("ios") {
        compilations {
            "main" {
                dependencies {
                    implementation("suparnatural-kotlin-multiplatform:fs-iosx64:$suparnaturalVersion")
                }
            }
        }
    }
    iosArm64 {
        compilations {
            "main" {
                dependencies {
                    implementation("suparnatural-kotlin-multiplatform:fs-iosarm64:$suparnaturalVersion")
                }
            }
        }
        compilations["main"].defaultSourceSet {
            dependsOn(sourceSets["iosMain"])
        }
    }
it's not pretty but relatively straightforward
you can add other dependencies as normal
c
huh
k
Seems like we're having the same issue. https://github.com/JetBrains/kotlin-native/issues/3668
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by