<@UF3V7CF4M> in <this thread> you mentioned that: &gt; The project has just one target (Android) de...

# multiplatform

[eygraber]

@Sebastian Sellmair [JB] in this thread you mentioned that:

The project has just one target (Android) defined. The Kotlin IDE plugin will detect that this is Android, and that commonMain is effectively an Android source set as well (that's the intersection of all platforms)

Is there a reason the plugin does this? I've occasionally run into issues because this allows Android/jvm code in common which can be a big pain when I add more targets later.

I usually start off my projects only targeting Android or JVM (because that's where I'm most comfortable so I can move faster), and later adding support for the other targets (native, js, etc...).

[darkmoon_uk]

On the face of it this doesn't sound like a helpful behaviour, interested in what the reason may be...

[Sebastian Sellmair [JB]]

Yes there is a IMHO good reason for this.
You are requesting a feature like “anticipating future targets” in the tooling, which we do not yet have! Until then, common source sets will try to show you all code that actually compiles inside it (which in a single platform case is the whole platform)

[Michael Paus]

I’d like to add the following:
1. This also works for projects which have an Android AND JVM target.
2. At first I thought that this is a bug but then I was told here that it’s actually a feature.
3. I use that heavily because it seems to be the only reasonable way to deal with projects with substantial dependencies on Java libraries which you cannot easily externalize via expect/actual.
4. This restricts me to this combination of targets but that’s all I need at the moment. If I should ever have to support iOS I am tempted to compile all my model stuff (Kotlin and Java libs) into a single shared library via GraalVM/native-image as it is done in Gluons JavaFX mobile world all the time already.

[darkmoon_uk]

All this time I thought that the 'common' API was fixed - are we to understand that the 'common' API surface is actually dynamically computed as the union of all target API's?

[Sebastian Sellmair [JB]]

No since 1.6.20 commonMain is computed as the union of your targets.
If you have linuxX64, iosX64 and jvm platforms, then the internal platform representation of commonMain is now not ‘common’ but,
`(linuxX64, iosX64, jvm)

[Sebastian Sellmair [JB]]

We want, at some point, to give the users full control on manually restricting source sets (to make it easer adding targets later in the future).

[darkmoon_uk]

Thanks @Sebastian Sellmair [JB], sorry just to repeat back to confirm my understanding:
• Before 1.6.20 'common' was a fixed API
• In 1.6.20 and beyond this has changed (improved) so that 'common' is the dynamically computed union of targets

[Sebastian Sellmair [JB]]

Yes! Just a minor addition:
The key differentiation factor here is if hmpp (hierarchical multiplatform) is enabled or not (which got enabled by default in 1.6.20)

[Michael Paus]

I have to admit that the wording is confusing me a bit. Is it really the union and not the intersection?

[eygraber]

Interesting, I always assumed that commonMain only allowed "common" Kotlin, and that this behavior was a bug.

Looking forward to the future ability to restrict this 😁

[Sebastian Sellmair [JB]]

@Michael Paus:
You should see the API intersection of all your platforms,
but the “platform description” is the union: Like: “What platform is commonMain? Oh it supports Platform A, B, C, D”.

But agree: Super confusing when we talk about this!

[eygraber]

@Sebastian Sellmair [JB] is there any hacky way to manually restrict the source set until the feature is built, or will we just have to have patience?

[handstandsam]

Just compile it for a non-android target and you’ll see if it’s compatible. Should be easy to do in CI or during development.

[eygraber]

@handstandsam the problem with that is if there's a lot of expect that isn't actualized for the non-android target it wouldn't compile.