https://kotlinlang.org logo
Join SlackCommunities
Powered by
Is there any way to add cinterops to custom native...
# kotlin-native
b
Is there any way to add cinterops to custom nativeMain sourceSet that all my native targets depend on?
📨 2
k
cinterop is configured on the compilation, not on the source set
👍 1
Copy code
targets.withType<KotlinNativeTarget> {
        compilations.getByName("main") {
            cinterops.create("phonenumbers") {
                includeDirs("c_interop/libPhoneNumber_iOS.framework/Headers")
            }
        }
        binaries.framework(listOf(RELEASE)) {
            isStatic = true
            linkerOpts.add("-Fc_interop")
        }
    }
b
Well shit then. I guess I'll revert to reusing the same src for all compilations then, which feels a bit hackish unfortunately.
k
your cinterops should not impact how you decide to setup your source sets
b
well it does. I have a c lib that all my linux targets use and i don't want to copy/paste its usage for all of them (since they're identical)
k
of course. i'm not sure how your cinterop setup impacts that.
i think maybe you're making an assumption that isn't true?
b
The issue I'm facing is getting access to cinterop generated functions from custom nativeMain sourceSet. From what you told me that looks to be impossible.
k
it definitely possible. source sets are compiled as a part of a compilation. cinterops are configured on the compilation level.
now, whether the IDE is smart enough to make the connections and give you all the features you're used to is another matter.
👍 1
m
AFAIK commonizer still does not work with custom cinterop.
b
Hmm, but nativeMain sourceSet does not have a compilation (or am I missing something)?
k
source sets don't have compilations, compilations have source sets
have you added nativeMain to any compilation?
the typical mechanism for this is through source set dependencies (
dependsOn
)
b
Not directly, I've made my linux sourceSet depend on nativeMain
And compiler is telling me that linux cinterops are not found in nativeMain context (trying to ignore IDE for now)
k
if the above is true about commonizer then it may require a different workaround
n
It could be the case that the Commonizer doesn't support the Linux targets yet. I wonder if this issue will be resolved in the Kotlin 1.5.0 release.
s
Commonizer support for c-interops was merged recently by me. The feature is expected in 1.5.20. To use c-interops in nativeMain, you will have to enable HMPP (and maybe a feature flag for c-interop commonization) We will also consider changing the dsl for c-interop to not be based upon compilations
🎉 7
(also note: unsupported targets will not break commonization in 1.5.0 and newer IDEs) (a.k.a optimistic commonization)
n
Which Linux targets will be supported by the Commonizer in Kotlin 1.5.20? Presumably that would at a minimum include these Linux targets: • linuxX64 • linuxArm32Hfp • linuxArm64
Will there be an official Linux Commonizer sample made available after the Kotlin 1.5.20 release?
It is likely that sharing some common platform (Linux) logic between the linuxX64, and Linux ARM targets (especially between linuxX64 and linuxArm32Hfp) will become increasingly common over time.
s
Hey Nick, we can jump into a Google Meet about this in the next days if you like talking about commonizer and your particular use cases 😊
a
Can I just joint you guys in that meet? If that okay
👍 1
b
I'd love to listen in too, actually. Or you could just record it and post it back here
👍 1
n
A group meeting (involving Kotliners that do Linux development via Kotlin Native) would be a good idea, however that would be very tricky to pull off with the various time zones (eg NZST starting from Apr 4), which would need to be synchronised (pick times that aren't too early nor too late).
a
I am flexible. You can almost discard me while selecting the time
s
Group meeting is fine 😊 Recording might be fine as well, but might make some folks feel uncomfortable? Let's see 😊 I'll make some time slot proposal today! Looking forward to it!
K 1
How about: ❌ 03.04, 11:00 CEST ❌ 03.04, 13:00 CEST ❌ 03.04, 16:00 CEST 4️⃣ 03.04, 22:30 CEST 5️⃣ 04.04 11:00 CEST 6️⃣ 05.04 11:00 CEST
3️⃣ 1
4️⃣ 1
2️⃣ 1
n
The 16:00 CEST option translates to 02:00 NZST which is very early in the morning 🌅.
s
@Big Chungus If okay for you, we could meet today 16:00 CEST. I’ll post a Google Meet link here and into the channel @napperley: We can still meet tomorrow, monday, … ☺️ We’ll find a spot 👍
b
Works for me, although I'm only interested in listening in 😀
Just curious is all
s
Oh, then let’s wait for @napperley to answer for an appropriate time slot!
b
Yeah, ignore me all together when planning, I'll adjust to whatever time works for you.
👍 2
Basically find a time suitable for @napperley (since he's the main guy here) and we'll adjust :)
n
@Sebastian Sellmair [JB] - Would Tue 06 Apr @ 08:30 NZST (22:30 CEST) be a workable time for you? This would give me enough time to look at the Commonizer (using whatever documentation/resources I can find), and select a suitable project that covers some of the use cases for Kotlin Multiplatform code sharing (with the Linux targets).
👍 1
s
Works for me ☺️
✅ 2
a
Me too
n
Then it is settled. Just need a call invite as mentioned in the Google Meet docs ( https://support.google.com/meet/answer/9303069 ).
16 Views
Open in Slack
PreviousNext
Powered by