Hi all, I have a few simple questions that essentially boil down to FFI etiquette / best practices:
I wrote a -sys crate for the SUNDIALS library. I know that Rust doesn’t currently draw a large numerics community, but I figured a SciPy-like-wrapper over some mature nonlinear algebraic and ODE solvers could go a long way to help. My questions are related to this activity:
SUNDIALS is BSD-3-Clause licensed. I don’t believe I need to license my -sys crate identically (I would prefer a 2-Clause or an MIT), but I feel like I should “advertise” the underlying 3-clause license – making my -sys crate the same propagates that visibly to crates.io. Is this a concern I should be having?
My -sys crate uses the SUNDIALS git repo as a submodule and builds the whole thing from source at
cargo build-time – thus I depend on
cmake(to build) and
bindgen(to generate FFI on the fly, in case build options are changed by features or weird platform defaults). This means any user of the crate needs to have CMake and Clang already installed on their system – is this asking too much? Everything I learned about Rust FFI came from an excellent tutorial, but it did not give much advice on pre-building across multiple platforms/configs and bundling the bindgen output (in particular, were I go to this route, what platforms/configs I should target?).
As mentioned, I am going to write an ergonomic wrapper over the
sundials-syscrate. Is it generally acceptable to coop the SUNDIALS name and call my project
sundialrs, or something else similarly inspired? Or is it better to not imply any affiliation and go for something entirely unrelated? After all, my wrapper will express API opinions very different from the authors of SUNDIALS. (Or does it not matter at all?)
Finally, not really a question, but if anybody has strong opinions on what a good ODE/root-finding wrapper should look like in Rust, I’d be very interested in hearing your thoughts. For something quick and simple I was going to go the SciPy route, but we have lots of stuff Python doesn’t – maybe another API else makes more sense!