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 writing the config causes unnecessary (?) cargo cache busting #70

Open
david-boles opened this issue Sep 21, 2024 · 0 comments

Comments

@david-boles
Copy link

david-boles commented Sep 21, 2024

Problem

Every time I rebuild my dioxus app, all crates that indirectly depend on manganis-macro are rebuilt.

Expected behavior

Only crates that have changes (e.g. my app) should be rebuilt.

Context

Running with cargo logging shows:

$ CARGO_LOG=cargo::core::compiler::fingerprint=info dx build --platform web
...
   0.193984191s  INFO prepare_target{force=false package_id=manganis-macro v0.3.0-alpha.1 target="build-script-build"}: cargo::core::compiler::fingerprint: fingerprint dirty for manganis-macro v0.3.0-alpha.1/RunCustomBuild/TargetInner { ..: custom_build_target("build-script-build", "/home/deb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/manganis-macro-0.3.0-alpha.1/build.rs", Edition2021) }
   0.193991000s  INFO prepare_target{force=false package_id=manganis-macro v0.3.0-alpha.1 target="build-script-build"}: cargo::core::compiler::fingerprint:     dirty: FsStatusOutdated(StaleItem(ChangedFile { reference: "/home/deb/git/my-crate/rust/target/debug/build/manganis-macro-24dd372a8b03c9b1/output", reference_mtime: FileTime { seconds: 1726897562, nanos: 349187625 }, stale: "/home/deb/.cargo/assets/config.toml", stale_mtime: FileTime { seconds: 1726897797, nanos: 944207436 } }))
...

Which I surmise is because the config is written unconditionally, regardless of whether it already contains the config we want:

pub fn save(&self) {
let current = Self::current();
if current == *self {
return;
}
let config = toml::to_string(&self).unwrap();
let config_path = config_path();
std::fs::create_dir_all(config_path.parent().unwrap()).unwrap();
std::fs::write(config_path, config).unwrap();

I assume this resultant behavior isn't intended?

In the bigger picture, I don't fully understand the rational behind this global config file that gets re-written every build. That seems ripe for race conditions when you have parallel builds on the same machine? I definitely don't have the full picture here but I wonder if it would make sense to have the cli pass in a path to a temporary file containing the config through an environment variable? Well, I guess not temporary temporary since it would also need a stable path across builds.

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

No branches or pull requests

1 participant