https://kotlinlang.org logo
#feed
Title
# feed
b

Big Chungus

06/04/2022, 4:32 PM
Here's a peek into the current KMP library distribution by target support NOTE:
jvm
category includes both, java-jvm and android-jvm
r

russhwolf

06/04/2022, 6:28 PM
I think you're missing a couple targets. I don't see android_x86, android_x64, or ios_simulator_arm64.
b

Big Chungus

06/04/2022, 6:32 PM
android_x86 ?? Is this new? I thought kotlin only had arm android native targets
Also the data is far from exaustive. It's just what I was able to extract from kamp.petuska.dev data
r

russhwolf

06/04/2022, 6:35 PM
Yeah there are 4 android native targets (which nobody uses, not even JB libs)
b

Big Chungus

06/04/2022, 6:35 PM
Noted, will need to add those into my scanner.
r

russhwolf

06/04/2022, 6:37 PM
They should show up in some of the Touchlab libs if you're trying to find them in your data
👀 1
b

Big Chungus

06/04/2022, 6:37 PM
Good to know for testing!
l

Landry Norris

06/04/2022, 7:01 PM
In case it helps:
Copy code
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.
b

Big Chungus

06/04/2022, 7:04 PM
Here's an updated version. Let me know if any targets are still missing.
r

russhwolf

06/04/2022, 7:08 PM
Nice. There’s something hilarious in the fact that android_x86 and android_x64 are smaller than the deprecated wasm
😅 2
b

Big Chungus

06/04/2022, 7:09 PM
And I bet all 24 of them are from touchlab 😄
l

Landry Norris

06/04/2022, 7:09 PM
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 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.
b

Big Chungus

06/04/2022, 7:11 PM
r

russhwolf

06/04/2022, 7:13 PM
They would be really good test targets if it were easier to spin up emulator tests for them.
l

Landry Norris

06/04/2022, 7:13 PM
I count 24 from that API as well. Looks like my library is one of them.
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.
b

Big Chungus

06/06/2022, 8:14 PM
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.
b

bashor

06/07/2022, 3:05 PM
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’d avoid using just
wasm
to avoid confusing with future K/Wasm artifacts
b

Big Chungus

06/07/2022, 3:09 PM
I'm using attribute values as is, so wasm and wasm32 are separated
Btw, how BOTH compiler option would get represented in gradle metadata?
i

Ilya Goncharov [JB]

06/07/2022, 3:13 PM
It publishs 2 variants of module with different values of js compiler attribute - legacy and ir There is no
both
value in gradle metadata
👍 1
b

bashor

06/07/2022, 3:29 PM
@Big Chungus Could you please share list of artifacts with
wasm
in DM?
b

Big Chungus

06/10/2022, 1:21 PM
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?
b

bashor

06/10/2022, 1:54 PM
^^ @svyatoslav.scherbina
b

Big Chungus

06/10/2022, 3:14 PM
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?
Some sort of purple?
#654FED is the logo hex
lol, didn't realise slack now expands color hexes!
b

bashor

06/10/2022, 3:43 PM
Color where? In the API docs?
No specific color for wasm yet
b

Big Chungus

06/10/2022, 3:45 PM
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
s

svyatoslav.scherbina

06/10/2022, 4:22 PM
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.
b

bashor

06/10/2022, 4:36 PM
@Big Chungus feel free to file an issue about color
b

Big Chungus

06/10/2022, 4:46 PM
@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)
👍 1
🙏 1
s

svyatoslav.scherbina

06/10/2022, 4:55 PM
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.
b

Big Chungus

06/10/2022, 5:02 PM
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"?
s

svyatoslav.scherbina

06/10/2022, 5:27 PM
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).
b

Big Chungus

06/10/2022, 5:31 PM
Great, thanks for confirming
👍 1
Finally managed to properly clean up all exceptions and special cases. Here's the latest and greatest tally.
4 Views