e.g.
[1 / n] Compiling foo v0.0.1
[2 / n] Compiling bar v0.3.5
...
When compiling a crate with a lot of transitive dependencies (which themselves may not be trivial), it would be nice to see about how many crates are left to compile.
When we compile with concurrent jobs don't we get the order jumbled?
An atomic counter could be used to keep a consistent order between threads. I will look into implementing this later today.
cc https://github.com/rust-lang/rust/issues/24335, specifically https://github.com/rust-lang/rust/issues/24335#issuecomment-99865880.
I'm somewhat wary of doing this because of:
rustc commands we're issuing.But that being said, I'd love to see progress here! Ideally we could get some form of hooks into the compiler indicating where it is and we could provide an interactive UI which indicates the progress of compilation (even concurrently), but that may be kinda difficult to implement :(
Wasn't this implemented with them fancy progress bars?
This was implemented by #5620, disabled by #5698, and re-introduced behind the unstable -Zcompile-progress option in #5716.
While it's definitely a useful feature, it has some quirks on Windows:
$ cargo +nightly install -f cargo-modules
Updating crates.io index
Downloaded cargo-modules v0.4.3
Downloaded 1 crates (541.8 KB) in 3.02sodules ... // <-- here
Installing cargo-modules v0.4.3
Downloaded structopt v0.2.12
Apparently, there was some message which was not fully erased before been replaced with the "Downloaded 1 crates (541.8 KB) in 3.02s".
Should I open a new issue for that?
@pravic I'm able to reproduce, I can take a look. It's not windows-specific. Thanks!
@pravic fixed in https://github.com/rust-lang/cargo/pull/6206
@ehuss Thanks!
Most helpful comment
This was implemented by #5620, disabled by #5698, and re-introduced behind the unstable
-Zcompile-progressoption in #5716.