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

spierce7

12/31/2021, 4:03 PM
Why isn’t the
iosSimulatorArm64()
target part of the
ios()
target yet? Same for
tvosSimulatorArm64()
and
tvos()
.
👀 4
s

Sebastian Sellmair [JB]

01/02/2022, 1:19 PM
Hey! In my first commits, this indeed was added to those shortcuts (because it seems intuitively like the right thing todo, right?). However I had to revert this change, because adding a target to such a shortcut is a breaking change: When using a library that does not support this new target, then upgrading to a new Kotlin Version will just silently break import (because of missing dependencies). We thought about how to solve such problems in the future and did not come up with some short term solution, yet. Personally, I would consider not using the shortcuts anymore and just declaring all targets explicitly. We do only have a long term solution for this, but are not ready to share it as of right now!
r

Rick Clephas

01/02/2022, 2:19 PM
IMO the benefit of the shortcuts is that you don’t need to configure the source sets and get e.g. the
iosMain
source set automatically. With that in mind how about making the targets of the shortcuts a parameter with a default value? This way the current behaviour stays the same while it allows developers to easily add an extra target. Then in a future release the new targets could become part of the default (once most of the libraries have added support for it).
s

spierce7

01/02/2022, 9:19 PM
the benefit of the shortcuts is that you don’t need to configure the source sets
100% agree with this.
When using a library that does not support this new target, then upgrading to a new Kotlin Version will just silently break import
I mean - it gives you a build error right? That kind of seems like something that comes with the territory. Also - it should be pretty rare in the future that new targets are added, right? I created a ticket about this so that the discussion can be tracked - https://youtrack.jetbrains.com/issue/KT-50615
s

Sebastian Sellmair [JB]

01/10/2022, 8:44 AM
We indeed did think quite a lot of how to handle this Situation. I really notice feeling quite defensive here, which is very likely a sign that this should indeed be re-thought in a more short to mid-term timeframe. Thanks for pinging and creating a ticket! Hope that we will find time to make improve this here!
s

spierce7

01/10/2022, 3:19 PM
Sorry - I didn’t mean to make you feel defensive! I’m just voicing an opinion. This is also the kind of of opinion that I could easily find myself disagreeing with my past self in a year or 2 if there is some unforeseen consequence 🙂
s

Sebastian Sellmair [JB]

01/10/2022, 4:53 PM
Oh! No worries at all! I felt defensive, because I would love to have a good argument for “why it has to be this way”, but to be honest: It’s also bothering me, but I just know, that I (and the rest of the team) will not be able to tackle it short to mid term) 😫 When we reverted the commit, we also started justifying this for us, and then never thought about it much. But the more I think about this, the more I do not like the situation! It would not pass the “tell an ex-coworker how this works”: Pretty sure my folks from QuickBird Studios would just raise their eyebrows when hearing this and think that this is stupid 😁 Soooo long story short: Should be changed and made more easy, but unsure yet how (and when)!
👍 1
s

spierce7

01/10/2022, 6:06 PM
Thanks for explaining. In the short term we have a clear work around 🙂
m

Marc Reichelt

10/21/2022, 8:26 AM
Upvoting the ticket since I think this is important. @Sebastian Sellmair [JB] any update on the
ios()
situation? Idea: how about having a flag in
gradle.properties
to introduce the behavior change? 1. In the first step
ios()
will preserve the old behavior, and the same for having this gradle property set:
kotlin.mpp.ios.sourceSetBehavior=legacy
2. By setting
kotlin.mpp.ios.sourceSetBehavior=allArchs
we can have
ios()
including the arm64 arch (also same for watchos, tvos, the likes) 3. Then, in a future Kotlin version, the new behavior becomes the default 4. After the deprecation cycle is over the flag + old functionality can be removed
could this work?
s

Sebastian Sellmair [JB]

10/24/2022, 6:47 AM
We have a replacement for this planned in 1.8.20
Shortcuts will very likely be deprecated in 1.9 or later!
2 Views