It would make more sense to me to focus on hierarc...

# kotlin-roadmap

[serebit]

It would make more sense to me to focus on hierarchical multiplatform and stabilizing the commonizer to make overall multiplatform development easier, rather than developing tunnel-vision on a single use case.

[akapanina]

Thanks for your feedback! We’re working on stabilising core Multiplatform functionality, we have a separate team that works on stability and UX of all common Multipaltform scenarios, not only Mobile ones.
For the next 3 months this team will be focused mostly on infrastructural works, which were hard to represent in a roadmap. We’ll be able to tell more in January, when the roadmap will be revised and renewed.

[serebit]

That makes sense. In fairness to the team, the only real issue I find myself having with multiplatform itself is the commonizer/hierarchical stuff. Everything else is pretty solid at this point. Most of my gripes at the moment are with Kotlin/Native, and I'm rather satisfied with the roadmap for that project.

[akapanina]

Btw, what’s your use case for commonizer? As I understood, you are mainly focusing on Linux targets. Is it posix commonization or smth else?

[serebit]

I am mainly focusing on Linux targets, yes, but I've been looking to expand support in my projects for more targets. The main problem I've run into is that supporting all Linux targets inherently requires an additional layer of common source sets to accommodate the differences between 32-bit and 64-bit POSIX APIs, as seen in https://gitlab.com/serebit/logkat/-/tree/master/src. This pushes the maximum depth of the tree to 3 source sets, which is the maximum that the commonizer can currently handle (to my understanding). However, in order to support a platform like Javascript, I would need to move the file-i/o classes to an additional common layer for JVM and Native, bumping the maximum depth to 4, which isn't supported.

[serebit]

There are also IDE issues with commonization that are orthogonal to the layer issue detailed above.

[akapanina]

Ah, I see. Unfortunately, every intermediate common source set has to be handled case-by-case, as it was done with ios preset - there’s no universal solution. AFAIK, @dsavvinov explains technical limitations for completely free source sets hierarchy in his talk for Kotlin 1.4 online event, you might be interested in that. Also he might point you at some workaround for your case I don’t see yet.

[serebit]

Oh yeah, I'm not expecting a universal solution to hierarchical source sets. The combinations I need are all already supported by the compiler (Linux targets alone, JVM + Native). The only real issue I have at the moment is the depth limitation, where the commonizer just gets confused if you have more than one level of source set between common and the actual platforms.

[serebit]

i.e. Common -> Desktop -> JVM + 32-bit Linux + 64-bit Linux -> Linux Platforms

[serebit]

That doesn't work, but Common->JVM + 32-bit Linux + 64-bit Linux -> Linux Platforms does.