Windows support

[jwharm]

Refactored the handling of values and valuelayouts, so that the bindings generator will treat glong and gulong values on Windows platforms as 32-bits values, which means they will be mapped to int values in Java and will use ValueLayout.JAVA_INT memory layout in struct definitions.

[jwharm]

This also fixes #16 .

[JFronny]

If I understand this correctly, the platform check is performed at build time rather than at runtime, meaning that binaries built on linux still won't work on windows. Couldn't it cast values to and from a platform-appropriate type in the generated code, thereby removing the need for different signatures?

[jwharm]

That would require much more than just a cast. The downcalls to native functions work with FunctionDescriptors, so they would need to be generated twice. The MemoryLayout objects that contain long ValueLayout fields, must be generated twice as well. And even for regular parameters and return values, a cast from long to int “behind the scenes” would probably lead to surprises when Windows users actually try to pass a 64-bit value in.

So tbh, I would love to do one platform-independent jar, but I don’t think it’s feasible.

[jwharm]

@JFronny I’ve been thinking some more about this, and the best solution seems to me, to release windows-, linux- and macos-flavors as separate jars. Would that be possible with Gradle? It should basically build the project multiple times with different parameters.

[JFronny]

You could create a SourceSet for each platform along with a Jar task and add their results as artifacts instead of the default jar. If we separate these, it would also allow using the proper Gir for each platform, which would be nice.

[JFronny]

Though an "api" jar without any impl and using the lowest common denominator would probably be helpful for libraries written on top of this.

[jwharm]

That sounds great. Would you have the time to change the build scripts? I'm still struggling trying to understand basic Gradle functionality.

[jwharm]

Though an "api" jar without any impl and using the lowest common denominator would probably be helpful for libraries written on top of this.

There's still the difference in parameter types between platforms. Every function/method/... that takes/returns a long parameter on Linux will take/return an int parameter on Windows.

I've considered generating int parameters on all platforms, but that would break on linux/macos when native code returns an actual 64-bit long value. And the reverse (generating long on Windows too, casting to int before calling native code) would break when a user would try to pass a 64-bit long value in.