[WIP] print status message when linking binary

[matthiaskrgr]

This adds a status print when linking binaries.

Linking can take quite some time when using lto so this adds some additional information.

I also had situations where the base/root crate was actually not build last in the dependecy chain which looked a bit strange because in most cases buiding the base crate also builds its binaries right after.

I started updating some of the tests but wanted to have some comments on the idea before I update the rest.

[rust-highfive]

r? @matklad

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Thanks for the PR! Cargo has historically been pretty bad about informing you what's actually happening at any one point in time, and it's always something I've wished we could do better at!

I'm somewhat hesitant though to add a per-target or per-binary message in the sense that it can on some projects cause a deluge of status messages. I'd love, though, if we could explore various ways of updating a status prompt with what Cargo is doing so it tells you at least one thing it's doing rather than attempting to print out everything perhaps?

I'm also slightly hesitant about the name "Linking" here in the sense that some binaries actually spend a significant amount of time during compilation (aka not in the linker), so it could be slightly misldeaing and cause somet to think that the linker is what's actually being super slow.

[matthiaskrgr]

I'd love, though, if we could explore various ways of updating a status prompt with what Cargo is doing so it tells you at least one thing it's doing rather than attempting to print out everything perhaps?

Make just prints the currently running command, and cmake also tells the user when linking is happening, I took some inspiration from this.

There is also ninja which when not having its output piped into something else, prints only a single line of the most recent job launched and updates that line. Do you mean something like this?

I'm also slightly hesitant about the name "Linking" here in the sense that some binaries actually spend a significant amount of time during compilation (aka not in the linker), so it could be slightly misldeaing and cause somet to think that the linker is what's actually being super slow.

Are you referring to linktime optimizations here? If not I don't think I understand what you mean.

[alexcrichton]

Yeah in general we don't want to be make/cmake as they're quite a bit more verbose than Cargo right now (plus there's always cargo build -v for that), but something like Ninja I think would be fine where the last line is basically a preview of one of the currently running jobs. That I think is "relatively easy" to implement and pretty portable across terminals at least.

And yeah "Linking" to me implies "running the system linker" but often times the final binary is stuck in optimizations, be them normal or LTO or whatnot.

[matthiaskrgr]

(plus there's always cargo build -v for that)

Maybe I can hook up the "Linking ..." message in the verbose output instead in the meantime...

And yeah "Linking" to me implies "running the system linker" but often times the final binary is stuck in optimizations, be them normal or LTO or whatnot.

Perhaps the term "Link time optimizations" is a bit trickier than I previously though... :)

[bors]

☔ The latest upstream changes (presumably #5063) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

I think in general this may just be a case where Cargo wants a far richer set of information coming out of rustc. In theory Cargo wants to be informed of all status updates that rustc is doing to always know what phase it's in, and that way Cargo could always print out at least one status for one crate so you can see what's going on.

That's a bit of a braoder issue though :(

For this PR though the message isn't quite right as Cargo doesn't know when rustc is invoking the linker or performing optimizations.

[matthiaskrgr]

Ok, I'm going to close this. I see that there are a bunch of issues with my implementation which I probably can't fix right now and a proper implementation requires some more thought.