Hi all, I have a multiplatform library, that also uses some CMake C Project. On Android, I use exter...

# multiplatform

[Vladimir Vainer]

Hi all,
I have a multiplatform library, that also uses some CMake C Project.
On Android, I use externalNativeBuild, on iosX64 I use: cinterop and custom cmake task.
Now, I want to use this library on desktop compose multiplatform project.
So I need to build and link a C project during jvm target build.
So I've added jvm target to my build gradle.
I've added my custom cmake task to the jvm target. But now the cmake can't find jni.h.
And I can't seem to find a good way to find a correct path to JDK from the build.gradle.kts.

System.getProperty("java.home")

Returns path to JRE, not JDK.

Is there a simple way to achieve this? Thanks

[jw]

I copy them into my project

[jw]

That also allows you to cross-compile

[jw]

Example: https://github.com/cashapp/zipline/tree/trunk/zipline/native/include

[Vladimir Vainer]

That sounds weird.
Why android {} has externalNativeBuild and jvm() does not?
It's the same thing

[jw]

I'm not sure what you're asking

[jw]

We build the JVM JNI libraries using Zig, but it's otherwise just a C/C++ compiler

[jw]

The Android SDK ships its own jni headers so those are available for the Android build

[jw]

cinterop doesn't need any additional headers

[Vladimir Vainer]

why it's so hard to build C library for jvm as part as gradle build.
I mean, not hard, but harder than it is to build a cmake project using ndk on android

[jw]

It's not common enough for Gradle to support and prioritize, whereas on Android is more common and they are not building a general-purpose system

[Vladimir Vainer]

Ok, thanks, I've added jni.h to my code, Not such big of a deal ;)

[Vladimir Vainer]

Ok so now that you got me curious about zig build system ;)
Please explain something for me:

pub fn build(b: *std.Build) !void {
  // The Windows builds create a .lib file in the lib/ directory which we don't need.
  const deleteLib = b.addRemoveDirTree(.{ .cwd_relative = b.getInstallPath(.prefix, "lib") });
  b.getInstallStep().dependOn(&deleteLib.step);

try setupTarget(b, ere&deleteLib.step, .linux, .aarch64, "aarch64");
  try setupTarget(b, &deleteLib.step, .linux, .x86_64, "amd64");
  try setupTarget(b, &deleteLib.step, .macos, .aarch64, "aarch64");
  try setupTarget(b, &deleteLib.step, .macos, .x86_64, "x86_64");
}

Here you add deleteLib.step dependency for every target but its only needed on windows.
So when you compile the linux target it will try to delete the non existing lib file?

[jw]

The relationship is the inverse. Each build adds itself as a dependency to the delete step. https://github.com/cashapp/zipline/blob/trunk/zipline/build.zig#L81

[jw]

So install depends on delete. And then delete depends on the compilation of all targets.

[jw]

You don't have to use Zig's build system to use Zig to cross-compile C/C++. We originally used cmake and just replaced CC. You can read about it here: https://zig.news/kristoff/cross-compile-a-c-c-project-with-zig-3599