Repository navigation
Tracking issue for -Z binary-dep-depinfo #63012
Description
Activity
- added 5 commits that reference this issue
on Aug 15, 2019 In #68298 we fixed binary dep-depinfo to be less eager to emit dependencies on dylib/rlib files when emitting rlibs and rmeta files, as we only need rmeta input in that case.
It was also noted that we currently do not correctly emit plugin dependencies (I'm not entirely sure of this, but seems not implausible).
8 remaining items
cargo-udepsuses the feature since the 0.1.33 release to figure out which dependencies were actually used during compilation, since save-analysis is going to be removed.The linux kernel uses the flag too: Rust-for-Linux/linux#2
Used by: Kbuild.
Status: we could get around it by making the build system more complicated (particularly if the kernel does not upgrade the minimum Make version), but it would be best to avoid that.
The linux kernel uses the flag too: Rust-for-Linux/linux#2
Used by: Kbuild.
Status: we could get around it by making the build system more complicated (particularly if the kernel does not upgrade the minimum Make version), but it would be best to avoid that.Apparently it is necessary to avoid recompiling in some scenarios: Rust-for-Linux/linux#2 (comment)
Without
-Zbinary-dep-depinforustc will only put the source files and the compiled output in the depinfo file. With-Zbinary-dep-depinforustc will also add .rmeta, .rlib, ... dependencies to the depinfo file. Without this changing a depensency wouldn't cause make to rebuild dependent crates. Cargo doesn't have this issue as it already knows the dependencies on it's own and only needs the depinfo file for the source file list, but make really needs everything.Reacted by Pierre FenollI can speak to the use-case in my case: we're using a large distributed build system at $work in which packages are automatically re-built if their dependencies change. Which, for example, means that if we for example need a patch to
rustcto work around some internal issue, thenrustcis re-built. And then anything that usesrustcis re-built. But without-Zbinary-dep-depinfoCargo doesn't understand thatrustchas changed since the version number remains the same, and so doesn't realize that it must also re-build the various Rust artifacts.I am confused by this statement. binary-dep-depinfo does not emit the path to the toolchain currently: https://github.com/rust-lang/rust/blob/1fa1f5932b487a2ac4105deca26493bb8013a9a6/compiler/rustc_interface/src/passes.rs#L490-L511
Exactly what is your setup? I don't understand why this would be working for you but not for bootstrap.Ah, so, to be clear, we don't currently use
-Zbinary-dep-depinfo. Instead, incremental builds currently just break if we ever happen to have to do this. What I wrote was aspirational: we want depinfo tracking in the hopes that it will let Cargo/rustc detect this situation (rustc changing without the version changing) and handle it correctly.Reacted by jynWe do currently use
-Zbinary-dep-depinfofor making cargo rebuild everything, however when incremental compilation is enabled, it is not enough to trigger a rebuild. The incr comp cache needs to be cleared too. In addition if a crate version changes, that seems to cause issues too.Cc #111329 (comment) which I believe should help explain why it's not currently enough for dependency version changes, I suspect a similar change for incremental may also be helpful but I haven't looked at incremental encoding/decoding.
For incremental it wouldn't help. Even if the encoding is exactly identical the encoded query results may have changed between versions. We need to clear the incr cache unconditionally if rustc changes.
Reacted by jynTo loop in some other tickets that have touched on "re-building if rustc changes" in the past: rust-lang/cargo#10664 and rust-lang/cargo#10367 are possibly relevant.
rust-lang/cargo#10367 is a different problem. That's about if the path to the compiler changes; the problem in this issue happens when the path and version output stay the same and only the mtine is different.
This is a tracking issue for
-Z binary-dep-depinfoadded in #61727.The cargo side is implemented in rust-lang/cargo#7137.
Blockers:
\\?\) paths, and I think we want to use only one style (whatever is compatible with make and other tools). See the PR for details.cc @Mark-Simulacrum @alexcrichton