Shim "Rust" Crate for C Library in Rust Project

help
#1

Toying with the idea of doing this, but not sure if it is somehow bad practice or I'm missing a better solution.

Situation:

  1. Writing a mainly Rust program, with a small kernel in C
  2. The C kernel relies on a C library which I don't expect users to have
  3. 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
  4. The C library is hosted on GitHub

What I want to do:

  1. 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.
  2. The shim crate's build.rs would just build the library, similar to a -sys crate, and then populate some pub constant in its src with the OUT_DIR it used when building.
  3. 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.
  4. 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.

#2

Typically you shouldn't have the build script fetch the source from github, instead include the C source in the crate itself when uploading it to crates.io. I recommend reading more in this article:

https://kornel.ski/rust-sys-crate

1 Like
#3

What Iā€™m thinking about is, the C source would be included in the shim crate which is downloaded directly by cargo instead of by the build script.

#4

Yeah, that's fine and is also what the linked article recommends. See the "build from source" section, which also talks about git submodules and such.

#5

Ok, thank you!