PKG_CONFIG_PATH_FOR_BUILD env var

[Ericson2314]

Currently, this library picks up

<build-kind>_<var> - for example, HOST_PKG_CONFIG_PATH or TARGET_PKG_CONFIG_PATH

This is fine, but this is quite non-standard. A standard way of doing things is instead using a _FOR_BUILD suffix:

• TARGET_PKG_CONFIG_PATH = PKG_CONFIG_PATH
• PKG_CONFIG_PATH = PKG_CONFIG_PATH_FOR_BUILD

This is what we do in Nipxkgs, and also what Meson does (see https://mesonbuild.com/Reference-tables.html#environment-variables-per-machine). This convention goes back to autotools.

CC @dcbaker @alyssais @lovesegfault

[alyssais]

I didn't open an issue here for a reason. :)

pkg-config-rs can't use PKG_CONFIG_FOR_BUILD, because Cargo doesn't expose to build.rs files whether they're being built for (in LLVM terminology) the host or the target. All the build.rs file knows is which architecture it's being built for. There's no way for it to know whether it should be looking at PKG_CONFIG or PKG_CONFIG_FOR_BUILD.

What would be feasible for this crate to implement is calling prefixed pkg-config executables (#53), but it's not easy due to the need to map from Rust triples to GNU triples.

[Ericson2314]

I do see the HOST and TARGET logic in here is pretty sketchy, but actually it might work out.

[Ericson2314]

See https://github.com/rust-lang/pkg-config-rs/pull/140/files I don't love it, but I think it's not unreasonable to get Cargo to pass something like our "offset" so it is improved in the future.

[sdroege]

@alyssais What do you think about the PR? This all seems rather hackish but then it's not very different from what was there before so...

Without changes at the cargo level there won't be any better solution, so maybe instead you'd like to take it over there?