Toying with the idea of doing this, but not sure if it is somehow bad practice or I'm missing a better solution.
Situation:
- Writing a mainly Rust program, with a small kernel in C
- The C kernel relies on a C library which I don't expect users to have
- I would like to maintain a seamless compile experience using cargo, where dependencies are handled as well as and in about the same way as someone using cargo would expect
- The C library is hosted on GitHub
What I want to do:
- Create a shim crate on GitHub (not posted to crates.io) and use it normally in Cargo.toml with a git source. The crate would use git subtree/submodule to keep the source of the library, allowing Cargo to get the library source when downloading the crate.
- The shim crate's
build.rs
would just build the library, similar to a-sys
crate, and then populate somepub
constant in itssrc
with theOUT_DIR
it used when building. - Using the shim crate as a build-dependency, the
build.rs
for my main crate would get the path where the library was installed through the aforementioned constant and pass it to the C compiler/linker and to rustc as necessary. - Everything would be linked statically to avoid any issues from dynamic linking this setup. Users who are building aren't expected to have root either so this is important anyways.
I don't have much experience setting up more complex builds, so I'm not sure if there are any pitfalls I'm missing here.