Thinking quickly, and perhaps wrongly, I dare to s...
# compose-destinations
g
Thinking quickly, and perhaps wrongly, I dare to say that the task would be to port the library to KMP and use dependencies from jbCompose. Hopefully, a task mostly accomplished at the Gradle configuration level? šŸ¤”
r
I would hope.. I’m only gonna know when I start looking into it. But I suspect I too am using some Android or jvm specific APIs 😜
šŸ˜… 1
g
I did a quick check and in your libs your only dependencies are:
Copy code
compose-navigation = { module = "androidx.navigation:navigation-compose", version.ref = "composeNavigation" }
and
Copy code
wear-compose-navigation = { module = "androidx.wear.compose:compose-navigation", version.ref = "composeWear" }
(which in a first phase we could exclude)
dependencies like
androidx-abc
are used in the playground
that’s why I risks to say that maybe we’re in luck šŸ˜…
regarding code generation, I’ve a lib that for the annotations module, something like:
Copy code
kotlin {
    explicitApi()
    jvmToolchain(11)

    jvm()
    iosArm64()
    iosX64()
    iosSimulatorArm64()
}
(for android & iOS) was enough šŸ¤”
the ksp module (with the processor etc) only uses jvm dependencies
Actually when I was coding it, I was basing myself in your lib and Rick Clephas KMP libs 😊
r
ughh I'm so sorry if you had to learn from my lib's code šŸ˜… There's a lot of stuff in there that I wish I had time to improve...
šŸ˜‚ 1
and yeah, the problem are not my dependencies... the core itself I'm sure uses some Android /java specific stuff, particularly in the custom NavTypes.. That said, I don't think it should be very difficult to replace with kmp firiendly APIs šŸ¤ž
wear dependency is used only for a specific wear artifact, so that is absolutely ok to ignore for now.. I mean, wear is wear, kmp doesn't really overlap there x)
g
true ^^
I’ll try to do a ā€œfind & replaceā€ when I have the time just for the fun of it šŸ˜›
who knows šŸ™