https://lib.rs/crates/fmod-core-sys
Disclaimer: bindings to non-free code. The sys bindings crate(s) are (MIT OR Apache-2.0) AND FMOD_EULA licensed. The Rust-idomatic bindings crate is MIT OR Apache-2.0 licensed.
I'm hoping to publish the -sys crates for my FMOD bindings relatively soon. As such, I'm looking for input/review on the idioms for publishing mostly mechanical sys crates like this. More specifically, I'd like input on:
- I do not set the cargo
package.links
key, as they do not compile/provide the FMOD symbols, merely link to them. - I add
lib/{arch}
to thecargo:rustc-link-search
path. - FMOD provides two binaries:
fmodL
, a logging binary for development use; andfmod
, for production use, without instrumentation. (Both are optimized release builds.) I currently choose between these based on the value of$PROFILE
. - The FMOD version number is
PRODUCT.MAJOR.MINOR (BUILD)
. I map this to cargo asMAJOR.MINOR.PATCH-PRODUCT.MAJOR.MINOR-BUILD
, wherePATCH
is a monotonically increasing version for patches of the bindings. - Bindings are pregenerated with bindgen. A script to regenerate the bindings is best-effort provided (but may not fully work as intended due to bindgen bugs cleaned up after by hand).
- Bindgen's
type_
is replaced withr#type
. - Bindgen's
__bindgen
identifiers have been replaced with an appropriatepayload
identifier, asunion
usage in the bound headers is for tagged unions. - Headers are shipped as part of the package, but not used.
- A
static
function is manually translated to Rust is marked#[inline]
- fmod-studio-sys's C headers also
#include
fmod-core-sys's C headers; this is done by symlink for the C headers[1] and Cargo dependency for the Rust symbols. - LICENSE.txt is the FMOD_EULA and is included via symlink.
Additionally, I don't have access to a macOS or Linux box to test installation on those. I'd appreciate any testing to ensure other people can successfully build the crate; if you get FMOD Engine[2] you should be able to get the fmod-rs crate building with just the information in the root README. If not, that's a documentation bug I'd like to hear about. (I'll probably need to link the platform docs[3] as well.)
Alternative linking idea I just had but don't know if I like: provide link_fmod!
and link_logging_fmod!
macros which expand to #[link = "fmod"] extern {}
or #[link = "fmodL"] extern {}
to let/require the consumer to link/choose which/how to link FMOD, rather than trying to provide this, since we are dynamically linking anyway and can't automatically find/provide a statically linked version...
-
no idea what symlinks will look like in the packaged version... ↩︎
-
Read the licensing terms first; usage is free under $200k revenue with attribution. ↩︎
-
And I just found a docs bug in them: they claim which lib is linked depends on
cfg(debug_assertions)
, not whether the build profile inherits fromrelease
ordebug
. This'll get fixed once the sys crates finalize what protocol they use for choosing which lib to link. ↩︎