cargo icon indicating copy to clipboard operation
cargo copied to clipboard

"cargo::rerun-if-changed" is not working. build.rs is run every time.

Open rkkoszewski opened this issue 6 months ago • 9 comments

Recently I noticed that "cargo::rerun-if-changed" has stopped working properly. To be specific, in the past, when the files marked with "cargo::rerun-if-changed" didn't change, then the build.rs script wouldn't run. But recently I updated to Rust 1.88.0 and noticed that build.rs keeps getting run on every "cargo build" or "cargo check", and only the target compilation seems to be skipped. I haven't seen anything related to this in the documentation. Is this a regression?

Code

I tried this code:

Cargo.toml

[package]
name = "test-build"
version = "0.1.0"
edition = "2021"

[lib]
path = "lib.rs" 

lib.rs

// Test library
pub fn hello() -> &'static str {
    "Hello from test-build!"
} 

build.rs

fn main() {
    println!("cargo::warning=BUILD SCRIPT RUNNING - {}", std::time::SystemTime::now().duration_since(std::time::UNIX_EPOCH).unwrap().as_secs());
    println!("cargo::rerun-if-changed=build.rs");
} 

I expected to see this happen: When I run "cargo build", I expect build.rs to run and print "BUILD SCRIPT RUNNING" and then the lib.rs file to be compiled. When I run "cargo build" a second time, given that I've made no changes at all, I'm expecting build.rs not to run and no "BUILD SCRIPT RUNNING" being printed, and the compilation to be skipped.

Instead, this happened: explanation When I run "cargo build", I expect build.rs to run and print "BUILD SCRIPT RUNNING" and then the lib.rs file to be compiled. When I run "cargo build" a second time, build.rs IS being run and showing "BUILD SCRIPT RUNNING" , and the compilation is skipped afterwards.

Version it worked on

It most recently worked on: (Not 100% sure) 1.86?

Version with regression

rustc --version --verbose:

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-pc-windows-msvc
release: 1.88.0
LLVM version: 20.1.5

rkkoszewski avatar Jun 29 '25 10:06 rkkoszewski

@rustbot transfer cargo

jieyouxu avatar Jun 29 '25 10:06 jieyouxu

Can you please run cargo build and then run CARGO_LOG=cargo::core::compiler::fingerprint=trace,cargo_util::paths=trace cargo build --verbose and post the full output?

ehuss avatar Jun 29 '25 14:06 ehuss

I'm hitting an issue on the xsf-rust project https://github.com/jorenham/xsf-rust

where the build script generates a file in the out_dir, and then it detects this file as being newer than the last build invokation and so re-runs the build script every time. It should be fine to write in out_dir I believe https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script

example log :

       Dirty xsf v0.3.2+0.1.3 (/home/redacted/Documents/redacted/code/xsf-rust): the file `target/debug/build/xsf-83bc54503dc402a6/out/xsf_wrapper.hpp` has changed (1761911758.276305173s, 20000000ns after last build at 1761911758.256305173s)

I would think given the build script runs and then generates the file, the out_dir content would always be dirty ?

Edit: Tried a smaller repro on a very simple project, and it's not triggering the issue at the moment Edit2: I can consistently repro on a bigger project, could it be a sort of granularity issue on last modified time coupled with a "time of check/time of use" kind of issue ?

something like : run build, record build start, build takes time, the recorded time for the out_dir will be ever so slightly later than the build start, compare out_dir modified time vs last build start : the out_dir has been modified after ? I'm guessing recording the "build end time" might make more sense ?

a repro might look like "have a build.rs script with an arbitrarily slow build process == time sleep, and output a random file in out_dir" will try that

Edit3: no luck with a slow build script, so something is changing the last modified time for whatever reason...

IceTDrinker avatar Oct 31 '25 12:10 IceTDrinker

@IceTDrinker

not sure but sounds familiar to #16168 and #16104?

indeed my bad, feel free to mark my comment as off topic, I mixed two things and was misled by the build.rs from the project which actually does not point to the file causing the issue, apologies

IceTDrinker avatar Oct 31 '25 13:10 IceTDrinker

i can confirm the same behavior in my machine!

cargo 1.91.1 (ea2d97820 2025-10-10)

rustc 1.91.1 (ed61e7d7e 2025-11-07)

mar10uane avatar Nov 26 '25 20:11 mar10uane

@mar10uane have you tried either

  • a newer nightly
  • disabling incremental compilation

epage avatar Nov 26 '25 21:11 epage

@epage HI disabling incremental compilation fix the problem.

Cargo.toml

[package]
name = "ruspackt_early"
version = "0.1.0"
edition = "2024"

[dependencies]


[build-dependencies]
syn = { version = "*", features = ["full"] }

[profile.dev]
incremental = false

mar10uane avatar Nov 27 '25 11:11 mar10uane

That is likely #16104 which has been fixed.

epage avatar Nov 27 '25 17:11 epage