cargo doc: Generate rmeta files for dependencies instead of compiling rlibs #4976
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
Thanks! Looks like there's some compile errors though? I'd be curious to hear thoughts from others from @rust-lang/cargo as well though. It sort of depends on what the most common way is to generate docs whether this is a good idea to do or not. I'd sort of lean towards "yes" personally, but wanted to gut check with others! |
|
Fixed handling of plugin dependencies. |
|
Hm maybe still some lingering errors? |
|
The remaining failures are caused by |
|
@alexcrichton I'm in favor. |
|
@alexcrichton I am also in favor. What do we think are the chances of getting #3501 ? |
|
@wycats I think it mostly just needs some work to get it done, AFAIK there's no fundamental blockers. |
|
Incidentally, new-rustdoc uses |
|
Pushed a fix for |
|
📌 Commit 9bb9dbd has been approved by |
cargo doc: Generate rmeta files for dependencies instead of compiling rlibs This makes `cargo doc` require only metadata (`.rmeta` files) instead of compiled libraries (`.rlib` files) for dependencies. This makes `cargo doc` faster in cases where rlibs are not already built and/or metadata is already available. Unfortunately, this is not a win for every workflow. In the case where the user has already compiled but has not generated metadata, it makes `cargo doc` do extra work. This is probably a common case, though tools like RLS and `cargo check` mean that many developers *will* have up-to-date metadata available. It would become an unequivocal win if `cargo build` and `cargo check` re-used shared metadata (#3501). For now, starting from a clean working directory, the following sequences of commands will become: * `cargo doc`: faster * `cargo build; cargo doc`: slower * `cargo check; cargo doc`: faster * `cargo build --release; cargo doc`: faster * `cargo check; cargo build; cargo doc`: no change
|
☀️ Test successful - status-appveyor, status-travis |
|
Would it not be possible to use |
|
@dwijnand technically it's possible! Last we tried to do that (a long time ago) it was pretty tricky in Cargo's internals keeping track of what's built and correctly handling incremental builds, but lots of time has passed since then so it may be easier today! |
This makes
cargo docrequire only metadata (.rmetafiles) instead of compiled libraries (.rlibfiles) for dependencies. This makescargo docfaster in cases where rlibs are not already built and/or metadata is already available.Unfortunately, this is not a win for every workflow. In the case where the user has already compiled but has not generated metadata, it makes
cargo docdo extra work. This is probably a common case, though tools like RLS andcargo checkmean that many developers will have up-to-date metadata available.It would become an unequivocal win if
cargo buildandcargo checkre-used shared metadata (#3501). For now, starting from a clean working directory, the following sequences of commands will become:cargo doc: fastercargo build; cargo doc: slowercargo check; cargo doc: fastercargo build --release; cargo doc: fastercargo check; cargo build; cargo doc: no change