Would be nice if there was a way to solve the prob...

# kotlin-native

[napperley]

Would be nice if there was a way to solve the problem of doing Kotlin Native development in an isolated environment without affecting the host's system environment 😄. Recently I have run into that problem when trying to use the EFL library ( https://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries ) in a Kotlin Native project ( https://gitlab.com/napperley/efl-hello ). I want to use the latest stable version of EFL (the libefl-all-dev Debian Package is missing key header/library files that should be present), however that is very likely to screw up the host system environment 😦. Building EFL from source for a Linux host requires satisfying a gazillion different dependencies 😱. Sadly a Kotlin Native developer, "cannot make their cake and eat it", this is why we can't have nice things 😦.

From the suggestions made from some Kotlin team members in the past ( https://youtrack.jetbrains.com/issue/KT-43501 ) on linking C libraries I don't think any of them use a Linux PC on a regular basis for Software Development; "It takes one to walk in ones shoes" in order to understand the issues they face, and how they do things.

[serebit]

You're also exploring EFL in kotlin-native, eh?

[serebit]

Also, I agree that the Kotlin team needs some developers that actively use Linux for development, if they don't have any already.

[napperley]

Unfortunately I cannot get the basic Hello World GUI sample ( https://www.enlightenment.org/develop/tutorials/c/hello-world-gui.md ) replicated in the Kotlin Native project due to the missing symbols/definitions. As mentioned earlier the Debian Package is missing some key files, hence an isolated environment is needed for Kotlin Native development.

[serebit]

Was that you who joined #e on libera.chat a few days ago and asked about that?

[serebit]

Well, if you'd stayed for another few hours, I would've told you that I actually have a solution to that 😛

[serebit]

The solution is to just reimplement EFL_MAIN in Kotlin, and add missing macro definitions to the .def cinterop file for EFL

[serebit]

https://gitlab.com/serebit/wraith-master/-/tree/master/efl

[napperley]

That is good to know. I have heard of cases where IntelliJ can run just fine without any issues in a FlatPak sandbox. Currently it is unknown if the Kotlin Native development tools (konan, cinterop etc) would also work in a FlatPak ( https://flatpak.org/ ) sandbox. @svyatoslav.scherbina Maybe the Kotlin team can shed some light on this.

[serebit]

Here's a working prototype of an EFL GUI written in Kotlin/Native that I managed to scrape together over the last week, for reference

[serebit]

Yeah, I'm lucky enough that my distro ships up-to-date EFL (and I have the know-how and ability to build and install the latest git version of EFL if I need to), but finding a Docker image that's suitable for building the project has been challenging to say the least

[napperley]

The FlatPak method (for anything GUI based) might be the solution for all Linux distributions that support it like Linux Mint for example.

[serebit]

Flatpak is great, but it's not always the best tool for deployment. I do think that the K/N dev tools could leverage sandboxing for building, but I'm not sure how they would go about it

[napperley]

My main motivation for giving EFL a spin with Kotlin Native is that I wanted a GUI library that supports the Linux Frame Buffer as a backend for resource constrained devices (where the JVM doesn't work well). Like SBCs (Beaglebone Black, Raspberry Pi etc) for example, especially ones where the graphics driver doesn't support graphics acceleration like the Beaglebone Black ( https://beagleboard.org/ ) for instance.

[serebit]

Which is... exactly what EFL is intended for, actually.

[serebit]

If you want to explore EFL K/N bindings, you should talk to raster on #e about getting bindings set up. I'm just using cinterop because it's convenient, but if you're developing something at scale, it might be worth looking into

[serebit]

They use a generator to build C bindings from a template, and that generator can apparently be used for other languages like Kotlin

[napperley]

Granted FlatPak doesn't cover every deployment use, however it works reasonably well for high level GUI applications depending on what system resources they need to access 😄. Unfortunately FlatPak won't work with EFL since it heavily relies on root access for many things, which is a bit of a bummer.

[napperley]

Ultimately I want to develop a GUI application that uses the Linux Frame Buffer for rendering (no Window Server), and runs on the Beaglebone Black. Cross compilation via an Image file (for the build root) would at the very least be able to provide an isolated environment that doesn't affect the host's system environment, however that comes with a different set of trade offs (eg can't run the program on the host).