Here's a peek into the current KMP library distribution by target support NOTE:

jvm

category includes both, java-jvm and android-jvm

I think you're missing a couple targets. I don't see android_x86, android_x64, or ios_simulator_arm64.

android_x86 ?? Is this new? I thought kotlin only had arm android native targets

Yeah there are 4 android native targets (which nobody uses, not even JB libs)

Noted, will need to add those into my scanner.

They should show up in some of the Touchlab libs if you're trying to find them in your data

Good to know for testing!

In case it helps:

val androidTargets = listOf(androidNativeArm32(), androidNativeArm64(), androidNativeX86(), androidNativeX64())

I can understand why most libraries don’t support android NDK, but there are cases where I need the NDK, and it’s a bit frustrating not having much support.

Here's an updated version. Let me know if any targets are still missing.

Nice. There’s something hilarious in the fact that android_x86 and android_x64 are smaller than the deprecated wasm

And I bet all 24 of them are from touchlab 😄

It does make sense. Android x86 and x64 are really only useful for NDK on an Emulator or a Chromebook. I have a few apps that work on my Lenovo Chromebook Duet with an Arm chip, but crash immediately on my Pixel Slate with an x64 chip.

I'm wrong https://kamp.azurewebsites.net/api/libraries?target=android_x64 there are others!

They would be really good test targets if it were easier to spin up emulator tests for them.

I count 24 from that API as well. Looks like my library is one of them.

I've finally managed to finish optimising my reworked scanner to handle nested artefacts so here's the latest and greatest library tally. Note those 109

unknown

category/family counts - they all seem to be js artefacts without org.jetbrains.kotlin.platform.type

org.jetbrains.kotlin.js.compiler

gradle metadata attribute for some reason. Is it safe to assume

LEGACY

backend for them? @bashor are you able to provide some details of why that might be the case? I've checked a few of them and they're mainly published between 2019 and 2020.

Is it safe to assume

LEGACY

backend for them?

Yes.

@bashor are you able to provide some details of why that might be the case? I’ve checked a few of them and they’re mainly published between 2019 and 2020.

Before we start publishing separate artifacts for K/JS IR and non-IR there was no need for an attribute to distinguish them. (cc @Ilya Goncharov [JB])

I'm using attribute values as is, so wasm and wasm32 are separated

It publishs 2 variants of module with different values of js compiler attribute - legacy and ir There is no

both

value in gradle metadata

@Big Chungus Could you please share list of artifacts with

wasm

in DM?

One more question. kotlin-test metadata has a

native

platform variant without

target

attribute. Can that be understood that the same variant should be used for ALL native targets?

^^ @svyatoslav.scherbina

And a bit out of topic, have you decided on the color for the new wasm target? We have green for jvm and android, blue-ish for native , teal for metadata and yellow for js - what's the new wasm gonna use?

Color where? In the API docs?

In the docs and any other references (mainly docs though). I'm using the same colours for my badges on kamp.petuska.dev so would be good to know new wasm before it goes alpha

One more question. kotlin-test metadata has a

native

platform variant without

target

attribute. Can that be understood that the same variant should be used for ALL native targets?

kotlin-test for Kotlin/Native is bundled with the compiler. The same klib is used for all Kotlin/Native targets. The kotlin-test library in Maven Central doesn’t in fact contain any code for Kotlin/Native, to the best of might knowledge.

@Big Chungus feel free to file an issue about color

@svyatoslav.scherbina is this a special case or a general feature for target-ambiguous targets? Can any other project using KGP produce metadata without target attribute for native variants (assuming no manual user interaction)

Can any other project using KGP produce metadata without target attribute for native variants (assuming no manual user interaction)

Sorry, I don’t get your question. What exactly should KGP produce in this case, and how it should be consumed? Metadata describes only API, but not implementation.

Let me rephrase that. First, some context:

kotlin-test

has a

nativeApiVariant

that declares

org.jetbrains.kotlin.platform.type: "native"

attribute. However, unlike all the other KMP libs with native targets, it does not declare

org.jetbrains.kotlin.native.target

attribute.

So I have two questions: 1. Can the

org.jetbrains.kotlin.native.target

attribute be missing in a third-party lib that uses KGP plugin to produce gradle metadata and has native targets? 2. Can the abscence of

org.jetbrains.kotlin.native.target

attribute be understood as "this lib supports all K/N targets"?

1. Can the

org.jetbrains.kotlin.native.target

attribute be missing in a third-party lib that uses KGP plugin to produce gradle metadata and has native targets?

I guess it can. For example, like this: https://github.com/JetBrains/kotlin/blob/fb9c5c13bd9e37b775648550437fe8264687839f/libraries/kotlin.test/build.gradle.kts#L77

2. Can the abscence of

org.jetbrains.kotlin.native.target

attribute be understood as “this lib supports all K/N targets”?

Unless someone explicitly modified the klib contents manually, a single klib (produced by KGP) can’t support multiple Kotlin/Native targets. So, if such a variant exists in Gradle metadata for a library, it probably doesn’t have any files, so (this variant) doesn’t actually provide any API. (If it does have files, then see above — the klibs are probably modified manually; it might be necessary to look into klib to find whether it contains any real code or not).

Great, thanks for confirming