Remove dep-info files as targets in themselves #47035
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Thanks for the PR! We’ll periodically check in on it to make sure that @alexcrichton or someone else from the team reviews it soon. |
kennytm
added
the
S-waiting-on-review
|
Hm so my main worry here would be in the area of breaking changes. This is technically a breaking change because there may be systems (I'm not immediately aware of any myself though) which could be relying on this behavior. The main consumer (I think) of these files, Cargo, would be ok with this change and I believe wouldn't need an update. The original project to add this feature (Servo) has since moved to Cargo and I believe no longer needs it. That being said I wasn't aware of direct ninja/rustc integration so there may be other integrations elsewhere that aren't using Cargo but are relying on this behavior. Could you detail a bit more about why this causes problems with Ninja? Does Ninja assume that all files listed as targets are outputs? Could a Ninja-local patch perhaps be applied? Could this be opt-in instead of a breaking change? |
Yes, it does; the relevant section of the Ninja user guide is here.
I'm not familiar enough with the range of Ninja use cases to say definitively. My reading of the manual is that it expects gcc's behavior, but I'm not sure how strictly.
Probably, though I would need a bit more guidance to know what the appropriate means would be for users to opt in. |
|
Also,
My motivation for this patch is to improve the support for defining rustc targets with the Meson build system, which uses Ninja as a backend. I'm not aware of any other such uses, but this issue is currently preventing the Meson support from working properly (see my incorrect attempt at a Meson PR here) |
|
ping @alexcrichton , what do you think? |
|
@acfoltzer ah sorry for the delay, fell off my radar. Thanks for the background info though! Would it be possible for the integration you're working with to perhaps postprocess the dep-info file to remove this output? I'm still pretty worried about causing a breaking change for projects, as I think a project using a |
|
@alexcrichton It would certainly be possible, but I would much rather see rustc just have consistent behavior (at least as an option) with gcc and clang. I'm sympathetic to the breaking change concern, though; do you have thoughts on the option styles I proposed above? |
|
@acfoltzer oh yeah I think either of those would be fine as well, we'd probably start it out as an unstable feature like |
This avoids a breaking change to dep-info output, putting the gcc/clang-compliant dep-info behavior behind a flag
acfoltzer
force-pushed
the
dep-info-tweak
branch
from
24c3756
to
8c09d29
Compare
|
@alexcrichton sounds great, 8c09d29 implements |
|
@bors: r+ Looks great, thanks! |
|
📌 Commit 8c09d29 has been approved by |
Remove dep-info files as targets in themselves If you ask `rustc` to `--emit dep-info`, the resulting dependency file contains a rule for producing the dependency file itself. This differs from the output of `gcc -MD` or `clang -MD`, which only includes dependency rules for the object files produced. Tools like Ninja often consume and delete dependency files as soon as they’re produced for performance reasons, particularly on Windows. In the case of `rustc` output, though, the recently-deleted dependency file is cached by Ninja as a target, and therefore triggers a rebuild every time. This very small patch removes the dep-info file from the list of output filenames, so it matches the behavior of gcc and clang.
|
💔 Test failed - status-appveyor |
|
@bors retry o_O what happened |
kennytm
added
S-waiting-on-bors
Remove dep-info files as targets in themselves If you ask `rustc` to `--emit dep-info`, the resulting dependency file contains a rule for producing the dependency file itself. This differs from the output of `gcc -MD` or `clang -MD`, which only includes dependency rules for the object files produced. Tools like Ninja often consume and delete dependency files as soon as they’re produced for performance reasons, particularly on Windows. In the case of `rustc` output, though, the recently-deleted dependency file is cached by Ninja as a target, and therefore triggers a rebuild every time. This very small patch removes the dep-info file from the list of output filenames, so it matches the behavior of gcc and clang.
|
💔 Test failed - status-travis |
|
@bors retry Took more than 30 minutes to compile librustc on the macs. |
|
⌛ Testing commit 8c09d29 with merge a6c95cd85ab8f4861d1a31887e821f69b3d7d3a2... |
|
@kennytm is there anything to do on my end to smooth this out? |
|
💔 Test failed - status-appveyor |
Remove dep-info files as targets in themselves If you ask `rustc` to `--emit dep-info`, the resulting dependency file contains a rule for producing the dependency file itself. This differs from the output of `gcc -MD` or `clang -MD`, which only includes dependency rules for the object files produced. Tools like Ninja often consume and delete dependency files as soon as they’re produced for performance reasons, particularly on Windows. In the case of `rustc` output, though, the recently-deleted dependency file is cached by Ninja as a target, and therefore triggers a rebuild every time. This very small patch removes the dep-info file from the list of output filenames, so it matches the behavior of gcc and clang.
|
☀️ Test successful - status-appveyor, status-travis |
If you ask
rustcto--emit dep-info, the resulting dependency file contains a rule for producing the dependency file itself. This differs from the output ofgcc -MDorclang -MD, which only includes dependency rules for the object files produced.Tools like Ninja often consume and delete dependency files as soon as they’re produced for performance reasons, particularly on Windows. In the case of
rustcoutput, though, the recently-deleted dependency file is cached by Ninja as a target, and therefore triggers a rebuild every time.This very small patch removes the dep-info file from the list of output filenames, so it matches the behavior of gcc and clang.