|
|
|
|
|
|
by jenadine
1091 days ago
|
|
|
> I've found that things like this are pretty straightforward with a build.rs - build.rs can't change the feature set. - what they usually do to bring dependency is vendor the C files within the crates, but when it comes to configuring to use an installed library and passing the right linker flags, this becomes really tricky. |
|
|
Can you be more specific here? You can totally do that based on OS, environment vars or even direct feature flags in the Cargo.toml. I've got a number of projects that do this and let downstream consumers decide what features they want. At the end of the day it's just a Rust program that runs ahead of the build and can do anything that you would be able to do in a normal command line program.
> ... but when it comes to configuring to use an installed library and passing the right linker flags, this becomes really tricky.
pkg-config[1] does all of that including returning linker flags. I can't think of a single case where I wasn't able to integrate with an existing library.
I'm not saying there are zero issues(I.E. passing some linker flags as a dependent crate gets annoying) but my experience having used C++ across a number of platforms(Win32, Linux, proprietary systems) before CMake existed and after it started getting wider adoption is that CMake has a significantly higher hurdle and is just harder to get things working correctly, especially under cross-compilation configurations.
[1] https://crates.io/crates/pkg-config