Kotlin/Native Support

[joelhandwell]

As issue https://github.com/MicroUtils/kotlin-logging/issues/21 was only dedicated for Kotlin/JVM and Kotlin/JS multi platform support, this issue is for Kotlin/Native support.

Kotlin/Native target platform is seen in org.jetbrains.kotlin.konan.target.KonanTarget.kt file line 43 as of 2018 August 16th:

sealed class KonanTarget(override val name: String, val family: Family, val architecture: Architecture) : Named {
    object ANDROID_ARM32 :  KonanTarget( "android_arm32",   Family.ANDROID, Architecture.ARM32)
    object ANDROID_ARM64 :  KonanTarget( "android_arm64",   Family.ANDROID, Architecture.ARM64)
    object IOS_ARM32 :      KonanTarget( "ios_arm32",       Family.IOS,     Architecture.ARM32)
    object IOS_ARM64 :      KonanTarget( "ios_arm64",       Family.IOS,     Architecture.ARM64)
    object IOS_X64 :        KonanTarget( "ios_x64",         Family.IOS,     Architecture.X64)
    object LINUX_X64 :      KonanTarget( "linux_x64",       Family.LINUX,   Architecture.X64)
    object MINGW_X64 :      KonanTarget( "mingw_x64",       Family.MINGW,   Architecture.X64)
    object MACOS_X64 :      KonanTarget( "macos_x64",       Family.OSX,     Architecture.X64)
    object LINUX_ARM32_HFP :KonanTarget( "linux_arm32_hfp", Family.LINUX,   Architecture.ARM32)
    object LINUX_MIPS32 :   KonanTarget( "linux_mips32",    Family.LINUX,   Architecture.MIPS32)
    object LINUX_MIPSEL32 : KonanTarget( "linux_mipsel32",  Family.LINUX,   Architecture.MIPSEL32)
    object WASM32 :         KonanTarget( "wasm32",          Family.WASM,    Architecture.WASM32)

    // Tunable targets
    class ZEPHYR(val subName: String, val genericName: String = "zephyr") : KonanTarget("${genericName}_$subName", Family.ZEPHYR, Architecture.ARM32)

    override fun toString() = name
}

Above list can give idea for implementation for different platforms.

[oshai]

Pull request is welcome. Any plan to do so?

[joelhandwell]

@oshai not so soon but I will when I develop Kotlin/Native app and if nobody else not started yet.

[joelhandwell]

@olonho @ilmat192 @homuroll @vvlevchenko is there any plan in Kotlin/Native support logging like this?

[jjzazuet]

+1 for KN logging! Thanks!

[olonho]

We would love to see such support, and probably kotlin.io.print is a good base for actual textual output, as it is outputs to natural standard out on most platforms.

[corneil]

It seems that it may be a reasonable solution to build a wrapper to Log4C to cover Linux, macOS and Windows

[RdeWilde]

Would love that, any work in progress or detailed plan?

[RdeWilde]

The author agreed to contribute his implementation to this project, but doesn't have time to do so, so someone should take it if his hands.

https://github.com/manijshrestha/kotlin-multi-platform-logging/issues/1

[animusnull]

I was working on a project which had a linux x64 native component, and utilized kotlin logging. I started a patch noted below. To add in this support. I am basing this off of zf_log. I chose this due to it's small base, and ability to work across linux, iOs, android, and macos.

That being said I'm new to kotlin native and cInterop. So may have some issues, or doing bad practice. I'm building the initial code in the area below. I based this off the 1.7.8 tag.

GitLab Repo Personal MR

[oshai]

@animusnull thanks for working on that! I am not working with kotlin native so don't think I will be able to provide any assistance. I suggest that you open the pull request in github so it will be possible to merge when ready.

[animusnull]

I've sort of hit a wall on figuring out how to publish the artifacts for linux native via kts. Once I get that sorted I'll look into how to submit a merge request.

[animusnull]

I just opened the MR.

The solution was including a static lib. Which means compiling the lib ahead of time and bundling it with the artifact. I opened a topic on kotlin discussions about best practices regarding this.

If we don't want to go that route then we can roll our own via println or something similar.

[oshai]

@animusnull thanks for working on #103 I will try to review it as much as I can. Can you also link to the discussion topic that you mentioned?

[animusnull]

Link to upstream

https://discuss.kotlinlang.org/t/kotlin-native-static-library-best-practices/15487

This is also a slack discussion where I got help on the initial issue

https://kotlinlang.slack.com/archives/C19FD9681/p1576614318012300

[IgorKey]

Guys, any plans to support KN?

[animusnull]

@IgorKey

There is a open pull request. I have artifacts on my CI/CD pipeline for linux. I just haven't had time to finish it up recently. It needs Windows, MacOs, and iOS. The HostManager in gradle throws an exception when opening the project outside of Linux which I consider a breaking feature.

[oshai]

see #103

[sgarfinkel]

Regarding #103 wouldn't it be better to take advantage of the syslog capabilities on each platform? With that PR you'd only get console logging capabilities.

For instance on Android, kotlin-logging could just delegate to https://developer.android.com/reference/android/util/Log and on Apple platforms delegate to the Unified Logger: https://developer.apple.com/documentation/os/logging

[oshai]

I think it makes sense. I see #103 as a default that can be override for each specific platform.

[animusnull]

It seems like for mobile we should use whatever native logging facility is open. For Linux native while I initially used a lib. I ended up going with a standard console out formatter. There isn't file out support, but I don't see a need too.

For mobile those look like the two best options. I'm not a mobile dev, so wouldn't be familiar enough to implement it.

[napperley]

Looks as though no actual progress has been made on adding support for the linuxX64 target. I have an alternative implementation for supporting the linuxX64 target, which only relies on the Kotlin Native Standard library, and POSIX (standard on MOST Linux distributions, with Android being one of the main exceptions). The implementation is based on the existing JS one. Also my implementation builds fine without any errors on a Linux X64 host, and can be published locally, although remote publishing hasn't been tested.

[napperley]

Logging on mobile platforms is very different from Linux X64 and Linux ARM platforms. The biggest mistake made with pull #103 is the mobile platforms support which shouldn't be applied to linuxX64. Both the Linux X64, and Linux ARM platforms handle logging exactly the same, or at least they are nearly identical. It would make sense to have a common source set that is shared between the linuxX64, linuxArm32Hfp, and linuxArm64 targets but NOT the mobile platform targets (Android, iOS etc).

[napperley]

Have managed to remotely publish my implementation to GitHub Packages without any errors. The GitHub Maven repository should be sufficient for testing purposes. Would welcome some feedback on my implementation.

[oshai]

@napperley thanks! Since I am not working with native myself, I think the way to go is to create a PR and gather some comments, and later merge it and publish.

[napperley]

@oshai - What title would be used for the PR since there is a existing PR ( #103 ) that does the same thing?

[animusnull]

@napperley

Just closed my pr, hopefully that frees you up. I have linux packages as well. Looking at your build.gradle.kts are you depending on a native main? I saw that if consumed from another multi platform lib that targeted several platforms it needed native main. Not sure if they fixed that issue, as it's been a while since I've looked into this.

[napperley]

@animusnull - Thank you for doing that :+1:, that makes things easier. I highly appreciate the work you were trying to do with the PR ( #103 ). In the build.gradle.kts file there is no executable function called in a binaries block which means a Kotlin Native library is created.

[oshai]

Just to update on the status: linux support was merged #119 but it still lacks deployed artifacts, and an assistance with that will be appreciated.

[altavir]

The hmpp mode allows sharing single native sourceset across all native platforms. I checked and it works in my fork.

[oshai]

Version 2.0.2 released with linux support. Main obstacle to release other natives artifact is in the build system. I am closing the issue for now, and we might move to circle ci build for more released targets in the future.

[LouisCAD]

There's also GitHub Actions that can build on macOS and Windows in addition to Ubuntu. I can link an example open source Kotlin Multiplatform libraries project leveraging it if you want.

[oshai]

Yes, thanks.

[LouisCAD]

@oshai There you have a workflow to check the project builds, and a workflow for releasing that also checks the pending publication upload before publishing the artifacts: https://github.com/LouisCAD/Splitties/tree/main/.github/workflows

[LouisCAD]

The publication checking depends on a module that is only included when passed the project property. Here's its build.gradle.kts file adapted for that project: https://github.com/LouisCAD/Splitties/blob/1936c6c7e445c048077d8b4b7bb1c13b99e0ca0a/tools/publication-checker/build.gradle.kts

[LouisCAD]

If you like that approach, I can consider making a Gradle plugin for the multiplatform project pending publication checking part, and its publish triggering part (that needs a retry logic as you can see). It'd simplify Splitties codebase at the same time :)

[altavir]

@LouisCAD we really need a plugin like that. I have my own set of plugins, which include publications as well, but I am not proficient with native yet. We can discuss it in slack.

[oshai]

@LouisCAD seems like such a plugin can help a lot, if it's also possible to sync the repo to maven central after publich (via bintray) it can be awesome! (here is the api: https://bintray.com/docs/api/#_sync_version_artifacts_to_maven_central)

[sgarfinkel]

@oshai @LouisCAD Travis CI also had macOs VMs for building, as an option.