These days, I’ve been playing with static Musl builds with native dependencies. The more I get to know all kinds of *-sys crates I’ve been trying to get to build, the more clear it has become that the build.rs system isn’t ideal at all: it’s diverse in a bad way, and that makes it error-prone and confusing. Everybody and their cousins are coming up with their build scripts, 90% of which all do the same thing: tell Cargo the name of the library to use, a path where to find it, and possibly how to link it (dynamic/static). Usually they are getting this data from two sources: from environment variables if they are set, and/or from pkg-config, if that’s present.
Now, I think that if most of the scripts are doing the same thing, with possibly implementations that are buggy or lacking features (I already send some PRs to add support for having the option of passing the static linking flags and using pkg-config.), there is a clearly benefical alternative: Cargo should use pkg-config directly to cover the majority of the cases where build.rs is currently used. I think that if there was a single field in
pkg-config="libpq" to tell how to get the linker flags and lib dir from pkg-config, most of the *-sys crates would simply use that.
Thoughts? I think this would be one, quite simple step to simplify the process and improve the ergonomics of linking native dependencies. Currently the process involves checking the docs/sources of every *-sys crate to see how they are configured. (If they even can be configured.) Note that I’m not saying that we should abolish build.rs scripts for good, just saying that a unified, simple alternative would do for the majority of the cases.