-flavor jvm or cinterop for jvm?

[dinuchiriac]

I'm working on a project which is heavily dependent on C libraries. In order to avoid Android NDK, we are using go mobile to build an android aar from c dependencies which make s life much easier, however, there are some limitations here as well like you cannot have 2 go-mobile packages in the same app.

We tried Kotlin native with cinterop which looks awesome, however, atm it looks like it is not possible to compile c code for JVM.

Doing a bit of research we come to cinterop -flavor jvm which looks like an internal flag that is not documented anywhere.
Question:

1. Is this going to be available anytime soon to the public, does it make sense to wait for cinterop support for JVM or there are no plans for this at all?
2. Do we have a public roadmap where we can see what the team is working on and what are the features we are going to see in next releases?

[olonho]

1. We do not have explicit plans on productization of JVM interop at the moment, however, considering open-source nature of Kotlin, we could consider PRs with such a feature
2. Public roadmap is not yet available

[dinuchiriac]

This sounds like there is something in place already but not publicly available yet, is it right @olonho ?

[olonho]

Sure, Kotlin/Native compiler is written on Kotlin/JVM using JVM version of interop to call into LLVM.

[ptitjes]

I would like to work on this as I would really wish to not have to rely on JNA anymore, which is really a pain to work with.

Notes

Here are some notes on my understanding on how the interop stub generator is used:

• kotlin-native.backend.native
  to generate files, hash and llvm stubs with flavor "jvm"
  uses NativeInteropPlugin (groovy) from kotlin-native-build-tools
  uses org.jetbrains.kotlin.native.interop.gen.jvm.main()
  uses org.jetbrains.kotlin.native.interop.gen.jvm.processCLib()
  with args

-generated $HOME/Code/external/kotlin-native/backend.native/build/nativeInteropStubs/llvm/kotlin
-natives $HOME/Code/external/kotlin-native/backend.native/build/nativelibs/linux_x64
-Xtemporary-files-dir $HOME/Code/external/kotlin-native/backend.native/build/interopTemp
-flavor jvm
-def $HOME/Code/external/kotlin-native/backend.native/llvm.def
-target linux_x64
-compiler-option -fPIC
-compiler-option -I$HOME/.konan/dependencies/clang-llvm-8.0.0-linux-x86-64/include
-compiler-option -I$HOME/Code/external/kotlin-native/llvmDebugInfoC/src/main/include
-compiler-option -I$HOME/Code/external/kotlin-native/llvmCoverageMappingC/src/main/include
-linker-option -L$HOME/.konan/dependencies/clang-llvm-8.0.0-linux-x86-64/lib
-linker-option -L$HOME/Code/external/kotlin-native/llvmDebugInfoC/build/libs/debugInfo/static
-linker-option -L$HOME/Code/external/kotlin-native/llvmCoverageMappingC/build/libs/coverageMapping/static

• KotlinMultiplatformPlugin
  uses KotlinNativeTargetConfigurator
  uses CInteropProcess
  uses KonanInteropRunner
  runs org.jetbrains.kotlin.cli.utilities.main() with tool name "cinterop"
  uses org.jetbrains.kotlin.cli.utilities.invokeInterop()
  uses org.jetbrains.kotlin.native.interop.gen.jvm.interop()
  uses org.jetbrains.kotlin.native.interop.gen.jvm.processCLib()
  runs org.jetbrains.kotlin.cli.bc.K2Native.main() with flavor "native"

Strategy

I believe that the 'c' in "cinterop" refers to the thing being interoperated with and not the where it is interoperated from. So adding an additional tool name "jvminterop" in org.jetbrains.kotlin.cli.utilities.main() doesn't really make sense to me.

Here is what I think I have to do:

1. Allow org.jetbrains.kotlin.cli.utilities.main() to have additional optional flavor cli option (keeping "native" as default flavor) when using tool name cinterop

2. Extend CInteropProcess to handle "jvm" flavor

3. Add code in KotlinJvmCompilation and KotlinJvmTargetConfigurator similar to the one in KotlinNativeCompilation and KotlinNativeTargetConfigurator to handle interops

Please tell me if that makes sense at all.

Questions

• I made crash my laptop two times while loading both the kotlin and kotlin-native projects in IDEA at the same time. Is there any way to work with those projects and do the least build work if I only want to work on the Kotlin Gradle Plugin and Kotlin/Native utilities?

• Is there any particular dependencies required to compile the stub generated with flavor "jvm"?

In advance, thanks for your help!

[ptitjes]

@olonho, could you provide me some guidance or point me to someone who can ?
Thanks in advance.

[artdfel]

Hello, @ptitjes! The problem with work on two projects is difficult to be managed. About the approach that you describe in the Strategy section - it seems consistent enough comparing with the existing interop. But I'm afraid that no concrete advice can be given here, as far as there is no planned design for this feature currently.
Anyway, feel free to ping here with any issues, we'll see what can be done and try to help as much as it's possible.

[jameswald]

I was hoping to avoid JNA or JNI by having Kotlin/Native automatically generate cinterop bindings that can be used with a jvm() source set. Is there any way to leverage cinterop to efficiently generate JVM-compatible C library bindings?

[SvyatoslavScherbina]

According to migrating issue tracking to YouTrack, closing this issue in favour of https://youtrack.jetbrains.com/issue/KT-39144