-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustix keeps rebuilding in my dependency tree. #575
Comments
Are you using an IDE, such as IntelliJ or another? Are you using |
I have vs code + rust analyzer open and bacon open at the same time. |
Is it possible that Some additional context is: rustix has recently had issues with build.rs not getting run when it needs to, which led to #544, #563, and #565, which seem to have fixed that issue, but now seem to be causing build.rs to run more often than it needs to. I don't yet understand how and when build.rs gets run in many situations, and don't yet know why this issue seems to be afflicting rustix when it doesn't seem to affect other crates that do rustc feature detection. |
Looking through the rust-analyzer vs code config I saw: Which corresponds to Line 153 in 1a9d8da
But also in that case wouldnt Line 154 in 1a9d8da
Cargo must have its own internal logic for skipping rebuilds before deferring to the build.rs |
https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorerun-if-env-changedname
Oh this looks useful: https://doc.rust-lang.org/cargo/faq.html#why-is-cargo-rebuilding-my-code |
Now that we appear to have a known-working fix for #526, we can investigate relaxing the fix. If #526 reappears, we now have a known-working state we can quickly revert to. Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds in some situations, so remove these. In theory, cargo should already be aware of these environment variables. In practice, there were reports of build failures which had the appearance of using an older version of rustc with build.rs output from a newer version of rustc, and it wasn't clear what was happening. But, it's possible that #563 fixes the issue properly. So let's try removing these rerun-if-env-changed lines, and see if the problem resurfaces. And, rerun-if-env-changed=TARGET is explicitly documented as being unnecessary [here]. [here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
Now that we appear to have a known-working fix for #526, we can investigate relaxing the fix. If #526 reappears, we now have a known-working state we can quickly revert to. Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds in some situations, so remove these. In theory, cargo should already be aware of these environment variables. In practice, there were reports of build failures which had the appearance of using an older version of rustc with build.rs output from a newer version of rustc, and it wasn't clear what was happening. But, it's possible that #563 fixes the issue properly. So let's try removing these rerun-if-env-changed lines, and see if the problem resurfaces. And, rerun-if-env-changed=TARGET is explicitly documented as being unnecessary [here]. [here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
I'm not sure if this is the same issue, as I get a slightly different info with
Unfortunately that doesn't tell which env var it is. I too am using VSCode with rust-analyzer. |
Same issue here (rustix keeps rebuilding) with same cargo verbose output, but using helix editor with rust-analyzer. |
Same issue for me with CLion + rust plugin |
Could people still seeing this issue please include what version of rustix they're seeing it in? I am currently unable to reproduce this, so any extra information you might be able to provide about the circumstances you see this in could be helpful. Thanks! |
I havent seen it in a while, I'll report back if I do see it again. |
sorry about that, issue seems to be fixed after updating from v0.36.11 to v0.37.11 |
Many thx - preliminary testing v0.37.11 in my case (helix editor with rust-analyzer) no longer shows the problem :-) |
I havent seen the problem since then so I'm going to go ahead and close the issue. |
Now that we appear to have a known-working fix for #526, we can investigate relaxing the fix. If #526 reappears, we now have a known-working state we can quickly revert to. Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds in some situations, so remove these. In theory, cargo should already be aware of these environment variables. In practice, there were reports of build failures which had the appearance of using an older version of rustc with build.rs output from a newer version of rustc, and it wasn't clear what was happening. But, it's possible that #563 fixes the issue properly. So let's try removing these rerun-if-env-changed lines, and see if the problem resurfaces. And, rerun-if-env-changed=TARGET is explicitly documented as being unnecessary [here]. [here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
Now that we appear to have a known-working fix for #526, we can investigate relaxing the fix. If #526 reappears, we now have a known-working state we can quickly revert to. Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds in some situations, so remove these. In theory, cargo should already be aware of these environment variables. In practice, there were reports of build failures which had the appearance of using an older version of rustc with build.rs output from a newer version of rustc, and it wasn't clear what was happening. But, it's possible that #563 fixes the issue properly. So let's try removing these rerun-if-env-changed lines, and see if the problem resurfaces. And, rerun-if-env-changed=TARGET is explicitly documented as being unnecessary [here]. [here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
This transitevely bumps rustix so it won't re-compile due to bytecodealliance/rustix#575 Change-Id: I616b6cb0d96bb9c4bf22c850253caefd6a7b273c Reviewed-on: https://gerrit.readyset.name/c/readyset/+/5515 Tested-by: Buildkite CI Reviewed-by: Aspen Smith <[email protected]>
Now that we appear to have a known-working fix for #526, we can investigate relaxing the fix. If #526 reappears, we now have a known-working state we can quickly revert to. Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds in some situations, so remove these. In theory, cargo should already be aware of these environment variables. In practice, there were reports of build failures which had the appearance of using an older version of rustc with build.rs output from a newer version of rustc, and it wasn't clear what was happening. But, it's possible that #563 fixes the issue properly. So let's try removing these rerun-if-env-changed lines, and see if the problem resurfaces. And, rerun-if-env-changed=TARGET is explicitly documented as being unnecessary [here]. [here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
Now that we appear to have a known-working fix for #526, we can investigate relaxing the fix. If #526 reappears, we now have a known-working state we can quickly revert to. Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds in some situations, so remove these. In theory, cargo should already be aware of these environment variables. In practice, there were reports of build failures which had the appearance of using an older version of rustc with build.rs output from a newer version of rustc, and it wasn't clear what was happening. But, it's possible that #563 fixes the issue properly. So let's try removing these rerun-if-env-changed lines, and see if the problem resurfaces. And, rerun-if-env-changed=TARGET is explicitly documented as being unnecessary [here]. [here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
Now that we appear to have a known-working fix for #526, we can investigate relaxing the fix. If #526 reappears, we now have a known-working state we can quickly revert to. Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds in some situations, so remove these. In theory, cargo should already be aware of these environment variables. In practice, there were reports of build failures which had the appearance of using an older version of rustc with build.rs output from a newer version of rustc, and it wasn't clear what was happening. But, it's possible that #563 fixes the issue properly. So let's try removing these rerun-if-env-changed lines, and see if the problem resurfaces. And, rerun-if-env-changed=TARGET is explicitly documented as being unnecessary [here]. [here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
Now that we appear to have a known-working fix for #526, we can investigate relaxing the fix. If #526 reappears, we now have a known-working state we can quickly revert to. Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds in some situations, so remove these. In theory, cargo should already be aware of these environment variables. In practice, there were reports of build failures which had the appearance of using an older version of rustc with build.rs output from a newer version of rustc, and it wasn't clear what was happening. But, it's possible that #563 fixes the issue properly. So let's try removing these rerun-if-env-changed lines, and see if the problem resurfaces. And, rerun-if-env-changed=TARGET is explicitly documented as being unnecessary [here]. [here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
My application has rustix in its dependency tree due to clap:
I have no idea why but sometimes rustix will just randomly trigger a rebuild.
I've never seen this for any other dependency before.
If I observe anything else that might explain whats going on I'll add it to this issue.
The text was updated successfully, but these errors were encountered: