Allow pkg-config checks to be skipped in CI environments that don't use or care about linking about pkg-config-rs HOT 7 CLOSED

Thanks for the report! I'm a little confused though as *_NO_PKG_CONFIG should skip everything related to pkg-config and return quickly, but is that not the case?

from pkg-config-rs.

The issue is that it causes probe_libary() to return an Err, which cause the build script to panic when it hits unwrap() and will prevent Cargo from building the code entirely.

from pkg-config-rs.

The build script in question clearly isn't prepared to manage without pkg-config (I believe _NO_PKG_CONFIG is meant to cause the script to build the library from source). Skipping it would just leave the linker unable to find the library.

However, when compiling my project the CI builds fail because pkg-config can't find the library this dependency requests.

Perhaps this specific issue can be solved instead? Could you link to the relevant Travis log?

from pkg-config-rs.

@SnirkImmington ah but the Err could be ignored, right? That is, if you drop it, then nothing panics?

from pkg-config-rs.

@SnirkImmington ah but the Err could be ignored, right? That is, if you drop it, then nothing panics?

I don't think I'm being clear here. This is not my build script. This is not my code. A dependency that someone else wrote is causing my builds to fail, and I have to hack on my CI build environment so my project can start compiling. This dependency's build script is "hard coded" to unwrap this error.

The underlying concern I'm feeling here is lack of control over the build process. This is, of course, something that happens when dependencies can have build scripts at all, but I didn't want to rewrite this dependency's build script. I spent a few commits trying to fix some environment variable that the error message hinted might be the cause.

Perhaps this specific issue can be solved instead? Could you link to the relevant Travis log?

I don't want to waste your time with looking at logs and suggesting different values for $PKG_CONFIG_PATH. If you don't think these changes are a good idea, I can close this issue and continue using my workaround.

Skipping it would just leave the linker unable to find the library.

This isn't always the priority in build environments. Even if our dependencies weren't able to find a dynamic linked library when we built them, we'd get the linker error immediately after when we run tests. This could be used to make sure that the Rust code of a library with specific C bindings can compile, without installing C libraries, setting up pkg-config, or running any tests that would immediately cause a linker fail.

I'm also pretty sure that running cargo doc in CI scripts to update docs shouldn't care about C bindings. What about creating binary releases? It shouldn't matter if the dynamic libs aren't in the build environment at that time that we build them. I just think this is a lot of forcing of others' code and requirements into the developer's environment, which the developer could have reasons to ignore.

I'm sure if you looked around at other Rust projects that have this issue, they've taken similar solutions - modifying the build scripts of their dependencies programmatically in CI, or removing the build.rs files altogether. We don't want to open PRs against all our dependencies or maintain forks just so our code can build.

from pkg-config-rs.

Cargo was designed to be pretty flexible around linking to native libraries, so you can use some of its escape hatches as well. For example if a links key is specified then you can override the build script entirely and just supply a pre-built copy.

I'd be pretty hesitant to add a configuration which forces pkg-config to "lie" that the dependency has been found when it actually hasn't, unfortunately. In general build scripts need to be robust if they intend to be used in lots of situations like this, so it may also be quite useful to upstream the build script changes you made perhaps?

from pkg-config-rs.

I'd be pretty hesitant to add a configuration which forces pkg-config to "lie" that the dependency has been found when it actually hasn't, unfortunately.

Okay, that's a fair call. Cargo provides some nice hooks for linking, and can keep using the value of $PKG_CONFIG if necessary.

from pkg-config-rs.