You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! I'm just discovering this library since I'm trying to stop using libGDX's Bullet bindings (no need for details here but libGDX makes a bunch of questionable choices that I want to avoid).
I have a question, why isn't this project setup in Maven like say, LWJGL in respect to the native parts?
In there you can see LWJGL provides not only the Java .jar/doc/src, but also variants for every platform LWJGL supports. So all you need in your POM to include the native parts of the specific version you're using, is just adding an additional dependency with the matching classifier (say, natives-linux in my case since I'm running amd64 linux).
Of course I see that you have quite a bunch of variants for the native libraries (f32, f64, single threaded, multi threaded, debug, etc) so it may be a lot of work, but it'd be cool to have at least the basics up there so the initial setup for trying out the library doesn't requires you to manually import the specific so/dll/dylib you're going to use.
I'm guessing the "basics" would be what you recommend in the readme, single threaded single precision. This can be simplified, I believe I saw some other library that had a natives .jar for each platform, and they just bundled all the architectures they supported for that platform in the same .jar (say, arm32, arm64, x86 and x86_64 inside the linux natives jar, x86 and x86_64 in the windows natives jar, etc). It makes each native .jar fatter the more architectures you support for that platform but it prevents you from having a bajillion variants in Maven, if that's a concern at all.
Just a general question, I have no stake in this nor real world use case for this since I'm barely dipping my toes at this moment.
The text was updated successfully, but these errors were encountered:
Hi! I'm just discovering this library since I'm trying to stop using libGDX's Bullet bindings (no need for details here but libGDX makes a bunch of questionable choices that I want to avoid).
I have a question, why isn't this project setup in Maven like say, LWJGL in respect to the native parts?
Look at this for instance https://repo1.maven.org/maven2/org/lwjgl/lwjgl/3.2.3/
In there you can see LWJGL provides not only the Java .jar/doc/src, but also variants for every platform LWJGL supports. So all you need in your POM to include the native parts of the specific version you're using, is just adding an additional dependency with the matching classifier (say, natives-linux in my case since I'm running amd64 linux).
Of course I see that you have quite a bunch of variants for the native libraries (f32, f64, single threaded, multi threaded, debug, etc) so it may be a lot of work, but it'd be cool to have at least the basics up there so the initial setup for trying out the library doesn't requires you to manually import the specific so/dll/dylib you're going to use.
I'm guessing the "basics" would be what you recommend in the readme, single threaded single precision. This can be simplified, I believe I saw some other library that had a natives .jar for each platform, and they just bundled all the architectures they supported for that platform in the same .jar (say, arm32, arm64, x86 and x86_64 inside the linux natives jar, x86 and x86_64 in the windows natives jar, etc). It makes each native .jar fatter the more architectures you support for that platform but it prevents you from having a bajillion variants in Maven, if that's a concern at all.
Just a general question, I have no stake in this nor real world use case for this since I'm barely dipping my toes at this moment.
The text was updated successfully, but these errors were encountered: