Provide better diagnostics for why crates are rebuilt #2904
Labels
A-rebuild-detection
Area: rebuild detection and fingerprinting
C-feature-request
Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Command-report
S-needs-design
Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Comments
Adding such debug information to |
|
I'm opposed to hiding that information behind a flag—in particular, the issue I had in #3067 would’ve been noticed far sooner. A (relatively) rare event like full recompilation of a dependency should—in my amateurish opinion—be communicated to the user as quickly as possible, and I think the regular Caveat: I am ignorant of most of cargo is designed. |
|
@davidbarsky yeah that sounds reasonable to me. We try to keep Cargo's UI pretty tight to ensure that you're not inundated with output, but perhaps we could do something like print |
|
@alexcrichton Thanks Alex! Got a quick question though: wouldn’t passing |
|
It's true yeah, |
|
Whenever I've encountered a recompiling issue it's usually very easy to reproduce, and opting into extra info via |
|
@alexcrichton @jwilm: Yep, I think you’re both right. Viewing information for a previous, one-off build is would probably take a lot of work and isn’t a particularly useful feature to have. |
carols10cents
added
A-rebuild-detection
|
FWIW, I am semi-regularly mystified by why cargo rebuilds something -- sometimes just on CI so I have little chance of debugging, like here in line 130 where even though it just built Miri, a Having some way of letting cargo tell me the reasons would be quite amazing. |
How would that work on CI? You can display the reasons today using the environment variable mentioned above. I have made some improvements lately so that it displays more relevant information. I can see some improvements:
But if this is CI, how would you go about diagnosing it? What kind of UI would you like? |
Well it's not interactive so the information has to basically be spot-on and not require further experimentation. That's what makes CI harder.
"it" is
Something like |
Oh, sorry, the original comment was out of date (being nearly 4 years old). I updated it: Yea, |
|
Ah, with I'm a little afraid using it on CI will just blow to an insurmountable amount of logs.^^ |
|
I just debugged locally a case where I tried the CARGO_LOG traceInstead I used Possibly this is not even considered a "rebuild" by cargo, it's "just" different feature flags, but the user-facing effect is similar. Maybe |
|
Hm, I don't see how And, yea, the trace doesn't help much because the hash changes, so as far as Cargo is concerned it is an independent thing. Cargo would need some kind of database for tracking artifacts to be able to correlate what changed.
|
Oh that's awesome, I should have checked the docs before posting! Sorry for that.
I'm invoking cargo through a script as we need some flags to make things actually work... I'll see if I can reproduce this with simple cargo invocations. |
|
To reproduce, fetch this branch and use a recent nightly toolchain with The second command then does |
|
Oh, I forgot that |
As in, the new feature resolver replicates the behavior of the old one? |
|
No, it ignores dev-dependencies if they aren't used, so |
|
Oh I see. But then |
|
|
6 tasks
|
#11407 is an attempt to provide recompile reasons in verbose mode (e.g. |
|
I'm going to reopen since this is not complete. The current implementation only tracks a small number of reasons that can trigger a rebuild, and doesn't provide after-the-fact reporting. The longer term plan is:
|
This was referenced May 4, 2024
epage
added
S-triage
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now Cargo can sometimes choose to recompile crates for surprising reasons, but it has lots of information internally to inform users as to why crates are recompiling. It'd be great to expose all this information!
Currently the best way to get this information is:
but then you have to wade through a bunch of other logging output. It'd be best if cargo would automatically do this on
-v. Something like "recompiling cratefoobecause: ...". Maybe even-vv.The text was updated successfully, but these errors were encountered: