Writing my first ever KotlinNative test applicatio...

# kotlin-native

[v79]

Writing my first ever KotlinNative test application, following the instructions at https://play.kotlinlang.org/hands-on/Introduction%20to%20Kotlin%20Native/04_AddingInteropToBuild . Not going well as gradle is not recognising compilations.main ('main' is in red). Full source is:

linuxArm32Hfp("pi") {
        compilations.main {
           cinterops {
               libcurl
           }
        }
        binaries {
            executable {
                entryPoint = "main"
            }
        }
    }

[v79]

As an aside, the examples provided in https://play.kotlinlang.org/hands-on/Introduction%20to%20Kotlin%20Native/04_AddingInteropToBuild are VERY different from the guidance on https://kotlinlang.org/docs/reference/mpp-dsl-reference.html#cinterops

[Kris Wong]

you can do compilations { "main" { ...

[Big Chungus]

have you tried

compilations {
  named("main") {}
}

[Kris Wong]

also works

[Big Chungus]

Wasn't aware @Kris Wong way is an option. That's probably the cleanest solution.

[v79]

Well, that's progress - libcurl still not found. I've got libcurl.def in src/nativeInterop/cinterop .

[Kris Wong]

yeah it's somewhat unusual syntax. but somehow it works.

[Big Chungus]

Ah, got that one myself. Gimmie a sec to find an example

[Kris Wong]

you need to add the path to the linker flags

[v79]

Worries me that the tutorial from the documentation is wrong in several ways!

[Big Chungus]

https://gitlab.com/kotlin-examples/game-of-life-mpp/-/blob/master/build.gradle.kts#L89

[Kris Wong]

you can do it in the def file or the gradle file. I find the gradle file is more appropriate

[Kris Wong]

i put all paths in the gradle file

[Big Chungus]

The example above handles it for all native platforms.

[Big Chungus]

I found that hard-coding the paths breaks on win/linux (works on one, fails on the other)

[Kris Wong]

iosX64("ios") {
        compilations {
            "test" {
                cinterops.create("OHHTTPStubs") {
                    includeDirs("c_interop/OHHTTPStubs/Headers")
                }
            }
        }
        binaries.getTest(DEBUG).linkerOpts("-Lc_interop/OHHTTPStubs")
    }

[Kris Wong]

in the def file, linkerOpts = -lOHHTTPStubs -ObjC

[v79]

So nothing at all like the tutorials or instructions then 🙂

[Big Chungus]

Kotlin Native is wild wild west

[Kris Wong]

that's an understatement 🙂

[v79]

Also, very mac/iOS focused, which holds no interest for me. I'm all about the Raspberry Pi.

[Big Chungus]

Indeed. I think most of the JB devs are on MACs and also android being the main driver for kotlin these days explains why IOS is a focus to promote KMM

[Big Chungus]

It's just the good old supply/demand

[v79]

I'm just hoping I can avoid writing in Python on the Pi. Or C, but I haven't written any C for 20 years.

[Big Chungus]

Once you nail down the initial setup K/N is a blast to work with (unless you decide to throw in multithreading into the mix, in which case hold on to your hat!)

[v79]

Lovely error here... Cause: cannot assign instance of java.lang.StackTraceElement to field java.lang.StackTraceElement.moduleVersion of type java.lang.String in instance of java.lang.StackTraceElement but I will work it out!

[Big Chungus]

Lol, never seen stack trace to fail to write itself 😄

[Kris Wong]

concurrency is a hot mess. avoid it if possible

[Big Chungus]

Just to be clear, concurrency is fine as long as you do it on a single thread. Parallelizm cases issues due to unique K/N memory model

[v79]

I think I am very far away from worrying about concurrency. Now, if only IntelliJ ran on the Pi...