Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unconditionally rebuilds all deps on rust nightly #436

Closed
matthiaskrgr opened this issue May 26, 2019 · 1 comment · Fixed by #441
Closed

unconditionally rebuilds all deps on rust nightly #436

matthiaskrgr opened this issue May 26, 2019 · 1 comment · Fixed by #441
Assignees

Comments

@matthiaskrgr
Copy link
Contributor

calling cargo build ; cargo build will cause sccache to try to rebuild the entire dep tree + root crate twice, even though nothing changed and it should technically not.

cargo clean ; cargo build ; cargo build
   Compiling serde v1.0.80
   Compiling ryu v0.2.7
   Compiling itoa v0.4.3
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 3.75s
   Compiling itoa v0.4.3
   Compiling ryu v0.2.7
   Compiling serde v1.0.80
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 1.16s

Cargo with rustc (and no RUSTC_WRAPPER) gets this right and does not rebuild anything on the second "cargo build" run.

This happens since this commit in the cargo repo: rust-lang/cargo@6b28a0c

Related cargo ticket: rust-lang/cargo#6976

@luser
Copy link
Contributor

luser commented May 28, 2019

I tried this out on my simple snippet crate and assuming I set CARGO_INCREMENTAL=0 so that sccache will cache the top-level crate I can reproduce it. I think the issue here is that sccache isn't caching the rmeta files. However, the cause of that seems to be that rustc is not listing the rmeta in its --print=file-names output. I ran cargo +nightly build -v on that snippet crate to get the compiler invocations, and added --print=file-names like sccache does internally and it only shows the rlib:

$ rustc +nightly --crate-name itoa /home/luser/.cargo/registry/src/github.com-1ecc6299db9ec823/itoa-0.3.4/src/lib.rs --color always --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=9de9e07ff885e8a5 -C extra-filename=-9de9e07ff885e8a5 --out-dir /build/snippet/target/debug/deps -L dependency=/build/snippet/target/debug/deps --cap-lints allow --print=file-names
libitoa-9de9e07ff885e8a5.rlib

I noted that there's an existing workaround in sccache that points to rust-lang/rust#54852 where rustc --emit=metadata --print=file-names prints the rlib name and not the rmeta, perhaps this is related?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants