https://kotlinlang.org
Join Slack
Was Heirarchical Multiplatform Projects released with 1.3.60? I don’t see anything in the release no...
# multiplatform
s
Was Heirarchical Multiplatform Projects released with 1.3.60? I don’t see anything in the release notes about it.
b
What is it?
l
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
I've done a lot of searching through slack and forums, and I still don't understand what it is
s
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
@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
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
Regarding Android and build variants, here's the WIP PR: https://github.com/JetBrains/kotlin/pull/2829#issuecomment-560174220
👌 1
s
@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
@spierce7 Having them declared in 
androidMain
source set is already supported and reaches 
main
created by AGP.
s
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
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
Why kind of issue did you experience?
Right now, kapt is not supported!
s
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
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
right
good point
I normally don’t like to fiddle with that stuff
s
Hihi, maybe vote for my PR then 🙄 https://github.com/JetBrains/kotlin/pull/2829
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by