Open bestouff opened 4 years ago
You can run Cargo with the CARGO_LOG=cargo::core::compiler::fingerprint=trace
environment variable, and it should display some information about why it thinks the crates need to be rebuilt. Perhaps that will give some clues on what's going on.
If you're able to reduce it to an example you can share publicly, I can take a look.
Here's something interesting I saw:
[2020-01-07T17:15:57Z INFO cargo::core::compiler::fingerprint] fingerprint error for legion v0.2.1/Build/Target { ..: lib_target("legion", ["lib"], "/home/xav/.cargo/registry/src/github.com-1ecc6299db9ec823/legion-0.2.1/src/lib.rs", Edition2018) }
[2020-01-07T17:15:57Z INFO cargo::core::compiler::fingerprint] err: current filesystem status shows we're outdated
Now the whole output:
Hm, I'm having a hard time determining the cause from the debug output. It looks like it thinks the parking_lot_core
build script needs to be re-run, which in turn triggers a bunch of other things to be re-built. Unfortunately there isn't enough detail in the debug output.
Can you distill it to a smaller reproduction? Maybe create a new (empty) project with just a few dependencies (it looks like it is either ggez
or legion
or both).
Do you have any .cargo/config
files anywhere?
With a fresh checkout of ggez
, doing cargo build --release
recompiles the top crate once more (but not twice).
My .cargo/config
contains:
[registry]
token = "something_very_long"
@bestouff I was wondering if you're still able to reproduce this problem on your laptop? If you are, can you maybe try with the latest nightly (2020-02-21 or newer). I've added some extended logging for fingerprints, so if you run with CARGO_LOG=cargo::core::compiler::fingerprint=trace
and post the output, it might help track down what is going on.
(This is a second cargo +nightly build
in ggez
)
@bestouff the logs you posted don't show anything being rebuilt.
Oh sorry, I checked too fast. I'll try to reproduce it with something else.
Here we are, this time using https://github.com/kaksmet/jpeg-decoder 83368db73c65e8265628a4161e8d7922e1e8c44e
This is the second build.
There are some strange mtimes being reported, where the fractional part is set to zero. Looking at libc
which is triggering the rebuild here, the mtime for the output of its build script (target/debug/build/libc-fa912be568aca87d/output
) is 1582985605.000000000
. However, the mtime for the build script executable (target/debug/build/libc-3d35f2bd3f0ad775/build_script_build-3d35f2bd3f0ad775
) is 1582985605.002970966
.
Cargo does some stuff to modify mtimes, and for some reason either the value is set to 0, or is being erroneously reported as 0.
A few questions:
unstable.mtime_on_use
set in any .cargo/config
files (like in your home directory)? It's probably unrelated, but just want to make sure.mount
and check which flags are set? And check /etc/fstab
, too.ls --full-time -R target
. (Place it in a gist to make it easier to read than a comment here.)Thanks! This is a bit of a puzzle.
Oh, one word: ecryptfs ...
~/.cargo/config
is quite empty (only a token = something
). /etc/mtab
line for my home dir:
/home/xav/.Private /home/xav ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=XXX,ecryptfs_sig=XXX,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
probably this ecryptfs bug. https://bugs.launchpad.net/ecryptfs/+bug/1890486
What I did:
cargo clean
cargo build
=> everything is rebuilt, that's OKcargo build
again => some crates are rebuilt, that's not OKcargo build
again => nothing is rebuilt, that's OKHappens on my laptop running Debian/testing, rust 1.40 from rustup, 8Gb RAM.
Doesn't happen on my desktop, sames OS, same rust, 20Gb RAM.
How can I help and provide debug info ?