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

spierce7

12/01/2019, 4:39 AM
Was Heirarchical Multiplatform Projects released with 1.3.60? I don’t see anything in the release notes about it.
b

basher

12/01/2019, 6:02 AM
What is it?
l

louiscad

12/01/2019, 7:34 PM
It's not complete. It's being used in kotlinx.coroutines, but some IDE features are still not there, resulting in red code when you are using these use cases. This is very likely to be the key feature of 1.3.70 though, where it should work well, including for Android targets (I'm following through a PR for the default source sets names for buildTypes, product flavors, local tests, instrumented tests…)
metal 1
👍 2
b

basher

12/01/2019, 8:22 PM
I've done a lot of searching through slack and forums, and I still don't understand what it is
s

Sam

12/01/2019, 8:26 PM
From what I gather, it is a way to do multiplatform for targets that share a similar lineage but not require file duplication or messy symlinks. For instance an iOS and macOS MPP project may be able to share 90% of their code but since MPP thinks of them as distinctly different, it requires workarounds to share code. HMPP will fix this.
s

spierce7

12/01/2019, 8:40 PM
@basher Sam mentions my limited understanding of it as well. To try and say it simpler: Currently you can’t specify a common iOS source set for the different iOS targets (iosArm32, iosArm64, iosX64), meaning you have to duplicate any
actual
definitions between all 3 source sets, which is annoying. People have been having to use hacks to work around this. HMPP should allow us to create a
commonIos
source set that all 3 of these source sets inherit from. Previously, any source sets that weren’t directly tied to a specific target were considered
common
, and thus couldn’t use any target specific code, but again, HMPP should fix this.
🎉 4
k

Kurt Renzo Acosta

12/02/2019, 12:39 AM
With what @spierce7 mentioned, this is in 1.3.60. You can see it in the docs here: https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#target-shortcuts
👍 2
l

louiscad

12/02/2019, 2:05 AM
Regarding Android and build variants, here's the WIP PR: https://github.com/JetBrains/kotlin/pull/2829#issuecomment-560174220
👌 1
s

spierce7

12/02/2019, 2:52 AM
@louiscad Should we be using
android<Variant>
source sets now instead of the android plugin source sets? What about the dependencies? Should the dependencies be added via the
android<Variant>
source set dependencies, or via the standard project level
dependencies
block?
l

louiscad

12/02/2019, 9:19 AM
@spierce7 Having them declared in
androidMain
source set is already supported and reaches
main
created by AGP.
s

Sebastian Sellmair [JB]

12/02/2019, 11:50 AM
Current implementation of the PR above would deprecate the usage of default Android plugin source sets. Using those source sets, with this implementation, will give you a deprecation warning. Regarding dependencies: You could still declare them both ways. I have strong opinions, that they should belong into the Kotlin source set extensions, but no one will force you (for now) ☺️
s

spierce7

12/02/2019, 2:58 PM
Having them declared in
androidMain
source set is already supported
I tried it a few weeks ago, but ran into issues, and went back to the standard android source sets.
s

Sebastian Sellmair [JB]

12/02/2019, 2:59 PM
Why kind of issue did you experience?
Right now, kapt is not supported!
s

spierce7

12/02/2019, 2:59 PM
I don’t use kapt. I’ve avoided it for compile times sake
👍 2
I don’t remember the exact issue, but I assume I was having trouble getting my dependencies to resolve in the IDE or something.
I also remember feeliing like it was inconsistent since I had to have the
AndroidManifest.xml
in the
main
anyways.
AndroidManifest.xml
didn’t work inside
androidMain
s

Sebastian Sellmair [JB]

12/02/2019, 3:12 PM
You can configure your android source sets to make it more consistent:
Copy code
android {
    sourceSets {
        getByName("main").run {
            manifest.srcFile(file("src/androidMain/AndroidManifest.xml"))
        }
    } 
}
Note: coded straight from my head. No idea how the API’s really look like!
s

spierce7

12/02/2019, 3:42 PM
right
good point
I normally don’t like to fiddle with that stuff
s

Sebastian Sellmair [JB]

12/02/2019, 3:47 PM
Hihi, maybe vote for my PR then 🙄 https://github.com/JetBrains/kotlin/pull/2829