https://kotlinlang.org logo
Channels
Powered by
#multiplatform
Title
# multiplatform
c

Cristián Arenas

01/03/2020, 2:00 PM
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

Kris Wong

01/03/2020, 2:02 PM
c

Cristián Arenas

01/03/2020, 2:13 PM
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

Erik Christensen

01/03/2020, 2:26 PM
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

Cristián Arenas

01/03/2020, 2:27 PM
@Erik Christensen I am doing that already, I had this working before updating Kotlin
k

Kris Wong

01/03/2020, 2:28 PM
you should do that to workaround a limitation in IDEA
you're accommodating the IDE
c

Cristián Arenas

01/03/2020, 2:29 PM
ah OK, that makes more sense
k

Kris Wong

01/03/2020, 2:29 PM
JB is working on the issue, hopefully it will be cleaned up in 1.4
🤞
c

Cristián Arenas

01/03/2020, 2:30 PM
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

Erik Christensen

01/03/2020, 2:33 PM
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

Cristián Arenas

01/03/2020, 2:33 PM
basically, my question is: does the meaning of 
iosMain
change if I rename 
iosX64
to 
ios
?
e

Erik Christensen

01/03/2020, 2:34 PM
iosMain
becomes the target's source set rather than a shared source set between targets when you do that
c

Cristián Arenas

01/03/2020, 2:35 PM
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

Erik Christensen

01/03/2020, 2:37 PM
I'm doing the multiplatform setup in buildSrc -- see multiplatform-library.gradle.kts
c

Cristián Arenas

01/03/2020, 2:38 PM
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

Erik Christensen

01/03/2020, 2:42 PM
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

Cristián Arenas

01/03/2020, 2:43 PM
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

Erik Christensen

01/03/2020, 2:45 PM
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

Cristián Arenas

01/03/2020, 2:48 PM
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

Kris Wong

01/03/2020, 2:48 PM
why?
what issue do you perceive with having 
iosMain
as the target's source set?
c

Cristián Arenas

01/03/2020, 2:51 PM
@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

Kris Wong

01/03/2020, 2:58 PM
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

Cristián Arenas

01/03/2020, 3:01 PM
huh
k

Kurt Renzo Acosta

01/05/2020, 11:09 PM
Seems like we're having the same issue. https://github.com/JetBrains/kotlin-native/issues/3668
2 Views
Powered by