Here's a peek into the current KMP library distrib...

# feed

[Big Chungus]

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

NOTE: jvm category includes both, java-jvm and android-jvm

counts_json.js

[russhwolf]

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

[Big Chungus]

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

[Big Chungus]

Also the data is far from exaustive. It's just what I was able to extract from kamp.petuska.dev data

[russhwolf]

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

[Big Chungus]

Noted, will need to add those into my scanner.

[russhwolf]

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

[Big Chungus]

Good to know for testing!

[Landry Norris]

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.

[Big Chungus]

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

counts2_json.js

[russhwolf]

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

[Big Chungus]

And I bet all 24 of them are from touchlab 😄

[Landry Norris]

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.

[Landry Norris]

I think the one library I created on mavenCentral supports the 4 NDK targets, only because it wasn’t much extra work and I use the NDK from time to time.

[Big Chungus]

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

[russhwolf]

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

[Landry Norris]

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

[Landry Norris]

I use the NDK for work. I found that running the tests wasn’t too bad, but accessing resources was a nightmare. I just gave up and removed my NDK tests (it was all video rendering, so hard to write unit tests for regardless) and verified the code visually.

[Big Chungus]

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.

counts3_json.js

[bashor]

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])

[bashor]

I’d avoid using just wasm to avoid confusing with future K/Wasm artifacts

[Big Chungus]

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

[Big Chungus]

Btw, how BOTH compiler option would get represented in gradle metadata?

[Ilya Goncharov [JB]]

It publishs 2 variants of module with different values of js compiler attribute - legacy and ir
There is no both value in gradle metadata

[bashor]

@Big Chungus Could you please share list of artifacts with wasm in DM?

[Big Chungus]

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?

[bashor]

^^ @svyatoslav.scherbina

[Big Chungus]

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?

[Big Chungus]

Some sort of purple?

[Big Chungus]

#654FED is the logo hex

[Big Chungus]

lol, didn't realise slack now expands color hexes!

[bashor]

Color where? In the API docs?

[bashor]

No specific color for wasm yet

[Big Chungus]

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

[svyatoslav.scherbina]

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.

[bashor]

@Big Chungus feel free to file an issue about color

[Big Chungus]

@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)

[Big Chungus]

KT-52739

[svyatoslav.scherbina]

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.

[Big Chungus]

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"?

[svyatoslav.scherbina]

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).

[Big Chungus]

Great, thanks for confirming

[Big Chungus]

Finally managed to properly clean up all exceptions and special cases. Here's the latest and greatest tally.

count4_json.js