On 28/10/2019 17:27, smaug wrote:
Quite often one has just a laptop. Not compiling tons of Rust stuff all the time would be really nice. (I haven't figured out when stylo decides to recompile itself - it seems to be somewhat random.)
I’m pretty sure there is no call to a random number generator in Cargo’s code for dependency tracking. Spurious recompiles are bugs that are worth filing so that they can be fixed.
If you manage to find steps to reproduce, building with a CARGO_LOG=cargo::core::compiler::fingerprint environment variable should print some details about why Cargo things some crate (and there for those that transitively depend on it) needs to be rebuilt.
https://github.com/servo/mozjs/pull/203 is an example of a fix for such a bug: a combination of a `build.rs` script being over-eager in using `rerun-if-changed` and calling something that ends up writing to the source directory.
`rerun-if-changed` is documented at https://doc.rust-lang.org/cargo/reference/build-scripts.html
On 29/10/2019 00:54, Gerald Squelart wrote:
It's a bit annoying to see things like "force-cargo-...-build" when nothing has changed,
That much makes sense to me: running `cargo build` is part of figuring out that nothing has changed. Cargo has a lot of dependency tracking logic, duplicating it all to avoid calling it would be unproductive and fragile. Running `cargo build` with a warm filesystem cache when there’s nothing to do should not take more than a couple of seconds. (Looking at the mtime of each source file.)
accompanied by lots of "waiting for file lock on package cache".
This line is printed − once − when Cargo is waiting for a filesystem lock. It showing up N times is a sign that there are at least N+1 copies of Cargo running concurrently.
It would be nice to run Cargo only once and tell it up-front everything it needs to do (with `-p foo` multiple times, or `--all`, or `default-memebers` https://doc.rust-lang.org/cargo/reference/manifest.html#package-selection) rather that having multiples copies competing for a shared resource.
-- Simon Sapin _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
