Hey there! Has someone also stumbled over how `iosSimulatorArm64()` , `iosX64()` and `iosArm64()` ...

# naming

[Marc Reichelt]

Hey there! Has someone also stumbled over how iosSimulatorArm64() , iosX64() and iosArm64() are named?
• iosArm64() is for a device
• iosX64() is for a simulator
• iosSimulatorArm64() is for a simulator
How could we name these better?

[Marc Reichelt]

Idea: deprecate iosX64() and add new iosSimulatorX64() method. Other ideas?

[louiscad]

Also have iosSimulator() like we have ios().

Did you file an issue on kotl.in/issue?

[Joffrey]

Technically simulator things should all be under the ios() shortcut IMO

[Stefan Oltmann]

@Joffrey If you happen to only test on real devices that would mean spending extra build time on something you don't need.

[Joffrey]

We're talking about defining target platforms. That's what ios() means - all iOS platforms. We could also split iosDevice() and iosSimulator() if we need the distinction. The point is that, as library author, I want to be able to say "all things iOS" and automatically benefit from future addition of targets. And application projects can select more precisely what they need by listing every platform specifically

[louiscad]

I like the iosDevice() thing

[Joffrey]

So I would say:

ios
  iosDevice
    iosDeviceArm32 (or iosArm32)
    iosDeviceArm64 (or iosArm64)
  iosSimulator
    iosSimulatorX64
    iosSimulatorArm64

[Joffrey]

+ deprecated aliases for the transistion
+ Similar things for watchOS and tvOS

[Stefan Oltmann]

@Joffrey We are on the same page now 🙂

[Sebastian Sellmair [JB]]

Shortcuts will have to be deprecated in the future, since they are not maintainable by us.
This was discussed in #multiplatform several times and there are tickets surrounding it.
Regarding naming of targets: This can be done, but is certainly not a priority over stabilising existing features!

[Sebastian Sellmair [JB]]

(There will be a replacement for the shortcuts that should be equally convenient)

[Joffrey]

Do you have links to those discussions/tickets? I find that hierarchical projects structure are a very important piece of the MPP library ecosystem. Not having that would be a pain for library developers. Shortcuts are just outlining a default hierarchy so people define the same things, aren't they? If JetBrains doesn't provide those, it means people will go about defining their own like darwin or apple and if names are not aligned, will we be able to benefit from common artifacts in consuming library projects? If the grouping is different, I think we won't. I actually wanted to push for a common hierarchy for everyone with common names for intermediate source sets so that the community is aligned on this

[Sebastian Sellmair [JB]]

Here is the internal document. Note, the proposal for the DSL changed again, but I will merge to master soon and send you the examples!

Multiplatform Proposal_ Replacing Target shortcuts with KotlinTargetHierarchy (1).pdf

[Sebastian Sellmair [JB]]

https://youtrack.jetbrains.com/issue/KT-53570/multiplatform-natural-hierarchy-prototype

[Joffrey]

Great! I'll have a look. Thank you. I like what I'm seeing in the titles if this discusses some kind of default hierarchy

[Sebastian Sellmair [JB]]

Relevant tests as example: https://github.com/JetBrains/kotlin/blob/sellmair/KT-53570-multiplatform-natural-h[…]lin/org/jetbrains/kotlin/gradle/KotlinTargetHierarchyDslTest.kt

[Sebastian Sellmair [JB]]

https://github.com/JetBrains/kotlin/blob/sellmair/KT-53570-multiplatform-natural-h[…]/jetbrains/kotlin/gradle/KotlinTargetHierarchyDescriptorTest.kt

[Sebastian Sellmair [JB]]

Definition of the “default” hierarchy:
https://github.com/JetBrains/kotlin/blob/sellmair/KT-53570-multiplatform-natural-h[…]adle/plugin/mpp/targetHierarchy/naturalKotlinTargetHierarchy.kt

[Sebastian Sellmair [JB]]

Btw @Joffrey: The naming of your source sets are not relevant for consumers of your library! You can freely choose a name that you like. Also: With hierarchical project support you also should not think too much about the hierarchy of your users project.
The source sets to source set visibility will be inferred based on the platforms (Gradle attributes)

[Sebastian Sellmair [JB]]

Merged to master. Check out nightly build tomorrow, if you would like to give feedback!

[Oleg Yukhnevich]

@Sebastian Sellmair [JB] quick question: why apple naming and not darwin? As for now, as I remember that almost all of projects, which configure K/N for macos/ios/etc uses darwin. Even coroutines uses darwin

[Sebastian Sellmair [JB]]

I stayed nearby Kotlin/Native naming in this case.

[Joffrey]

One remark about the document. Was it considered to provide an automated natural hierarchy wiring with custom-prefixed source sets? Like a whole hierarchy with a prefix?

Here is what I had done for the Krossbow project:
https://github.com/joffrey-bion/krossbow/blob/main/buildSrc/src/main/kotlin/SourceSets.kt

Towards the end of the file you can see the "default natural hierarchy" but it still doesn't exclude creating whole independent hierarchies with a prefix, like here where I need independent hierarchies for testing:
https://github.com/joffrey-bion/krossbow/blob/main/autobahn-tests/build.gradle.kts

[Sebastian Sellmair [JB]]

The merged implementation will allow you to create independent hierarchies for main/test/custom/..

[Sebastian Sellmair [JB]]

Glancing over your code: this should be expressible

[Joffrey]

Awesome. Thanks a lot for all of this. Indeed what I needed most was the convenience to define hierarchies and source sets, not the part to automatically declare groups of targets. So overall it's a nice move forward

[hfhbd]

What about watchosDeviceArm64? 😄

[Sebastian Sellmair [JB]]

Context?