bulletrs
bulletrs copied to clipboard
not-fl3
Publish to crates.io
Need to figure out the correct way to produce library from Bullet3 and the best way to distribute it with that crate.
Add entire bullet source to crate dependencies? Put only binaries somewhere? Make a link to the libs in readme?
The method that might prove most effective is bundling the sources like the libsqlte3-sys crate does when given the bundled option. This makes distribution and building on platforms like Windows much, much easier. That crate uses the gcc crate to compile the source, which also gives stronger version guarantees than depending on a system-installed library.
Checkout https://github.com/jgallagher/rusqlite#notes-on-building-rusqlite-and-libsqlite3-sys
I think that bullet3d is a bit too complicated to dealing with it throw cc crate.
I am considering participating in cargo-native as an option (https://paper.dropbox.com/doc/Declarative-native-dependencies-iLRUq6Zt2tPtLWE9IyLqS). Like check what people will do and try to fit bulletrs to this somehow.
Well, I built the hugest build.rs ever :) https://github.com/not-fl3/bulletrs/blob/buildrs/bulletrs-sys/build.rs
It was built with semi-automated parse of cmake output. Seriously considering to describe that process and propose to cargo-native as a way to create cc-rs scripts for cmake-based huge projects.
There is only one platform-dependant string now - .define("_LINUX", None) for only one of bullets libs. I think defining "WIN32" or "DARWIN" should be enough for other platforms. Going to do it after few days of linux-only testing.
I have no experience with build.rs files of that scale, so any comments and test reports are highly welcome.
That build file is probably cleaner than most large CMake files I've seen :/
Removed all UI and Networking from bullet for windows build https://github.com/not-fl3/bullet3/compare/not-fl3:789258448fb95ebdb08a41c0db0efa63a711b877...rustbindings And now it's working both on linux (with Graphics Debugger, UI, Networking and everything) and on windows (with Direct connection only). Open for PR's for MacOs :) It works for me and I am going to use it that way.
I had 2 alternatives of that build.rs approach.
- cmake-rs
- link with binary object file in build.rs
cmake-rs force users to have cmake on their machines. And it is probably well. But the problem here is bullet's CMake file. For both windows and linux it should be deeply modified :( For windows specifically - bullet is supposed to be built with Visual Studio. And pros of cmake-rs - easy to maintan and update bullet.
binary object file - may be the best thing for users - if I'll provide it for all of the platforms. And may be convinient for me - it is possible to set up travis to build it somehow. But also requires a lot of work on Windows to build that file.
And build.rs approach. I thought that its possible to autogenerate build.rs file from make's output, but actually it is not - too much platform-specific things. So it will be hard to update to new bullet's versions. And with "ccache" development iteration cycle is pretty fast - comparable to cmake's.
Seriously considering to describe that process and propose to cargo-native as a way to create
cc-rsscripts for cmake-based huge projects.
Please do! Would be very helpful.
Some time passed since I made this and in the hindsight I think that making build.rs from the cmake output was not so good idea. While it works for bullet for some specific platforms its definitely not a general purpose solution :(