Dependency being constantly rebuilt due to 'env_metadata' being set to 'true' about pkg-config-rs HOT 8 CLOSED

I believe this is the intended behaviour. The general assumption of cargo is that the whole build happens in the same environment, and if your environment variables change in a way that affects any of the build steps then it will rebuild that part.

Why do you change your environment, what's the use-case of this?

from pkg-config-rs.

It's one of the main goals of Nix/NixOS, instead of "polluting" your own environment with the dependencies of every project you ever done, you create temporary environments adapted to each project. Those environments can also be written down (like a Dockerfile I guess) and are reproducible.

Before #105 I had to go in such an environment (with pkg-config, openssl, etc.) only once => for the first build, and then I could leave it and use cargo build without any issue outside the said environment, as deps using pkg-config-rs were not getting rebuilt.

But now, if I leave this environment, the dependencies are getting rebuilt and so the build fails. If I also add a new package to the environment, it will rebuild every single dependency using pkg-config-rs, (on an amethyst project, ~10 dependencies + the one that depends on them, which is ~50 dependencies).

It is really annoying 😞 I can't use my IDE properly anymore. Building these environments also became very hard as any edit to the PKG_CONFIG_PATH will trigger tons of rebuilds. If you don't have any workaround, I will be forced to use a fork to revert this PR

from pkg-config-rs.

I don't think such a use-case is generally supported by cargo. This is not only an issue with pkg-config but also with other libraries linking to system libraries and taking information from environment variables (as most due), and correctly declaring that they use these environment variables.

I think you want to create an issue for cargo here about supporting "partial builds" in some way. This wouldn't be a problem if cargo allowed to output build results for all the dependencies separately and allowed to use those for building the final crate.

That this worked before for you was a bug, and the problem you're running into now is caused by the general design of cargo.

from pkg-config-rs.

Well I'll open an issue. The thing is, this is the kind of issue that will probably never get resolved, I guess I'll have to fork this repo.

from pkg-config-rs.

You'll probably sooner or later run into the same problem with other crates linking to system libraries and not using pkg-config though, so I guess this really needs to be solved in cargo for you or you need to change your workflow.

For cargo, this is just another of many things where its current build process and especially handling of system libraries is rather suboptimal. I think that needs some general redesigning, and as such I agree with you that this is probably not going to be solved anytime soon there.

from pkg-config-rs.

Hey @Litarvan, i'm running into this issue on NixOS as well, was there a workaround, or another issue i can subscribe to to track progress of this bug? Thanks!

from pkg-config-rs.

I didn't open an issue since I knew it would never be resolved, I did a fork with the fix here : https://github.com/Litarvan/pkg-config-rs
That's the only solution I found

from pkg-config-rs.

I didn't open an issue since I knew it would never be resolved, I did a fork with the fix here : https://github.com/Litarvan/pkg-config-rs
That's the only solution I found

Ah! Understandable. Thanks for pointing to your workaround though 👍

from pkg-config-rs.