@dtolnay thx, i didn't see that PR. Do you think cxx could adapt the approach to other similar crates like static_files change_detection? It has a builder that allows to enable change detction print statements, and afterwards it finalizes it.

The issue with cxx is that it produces a cc::Build directly - making it somewhat inconvinient when additional configurations are needed. Perhaps we can introduce a new Bridge or CxxBuild struct?

    cxx_build::new()  // empty CxxBuild
        .add_bridge("src/map_renderer.rs") // add a single bridge file
        .change_detection() // enable "rerun-if-changed" printing
        .to_bridge()  // consume CxxBuild and create cc::Build -- prints rerun-if-changed here
        .includes(&include_dirs)  // Just as before - operations on the cc::Build
        .file("src/renderer/bridge.cpp")
        .flag_if_supported("-std=c++20")
        .compile("maplibre_rust_map_renderer_bindings");

I don't think a separate builder type is justified. But it could be done using CFG.

Thx, I created #1463 to do that

Beginning in cc version 1.0.74 the cc crate has started printing some rerun-if-env-changed lines by default, so the downsides in #26 are already being paid. (From the description of the relevant cc PR it sounds like the downside was not understood when making that behavior change.) In that case this PR is fine after all and will not make things worse.

Can we add a way to opt-out of this? One of the files I give to bridges is autogenerated by my build script immediately before. So this file always has a timestamp that is newer than the "last build" timestamp kept by cargo. As a consequence, cargo will always consider that file changed and rerun the build script on every build.

The only hacky workaround that I'm aware of is using File::set_modified to fake a modification time older than the build script's start timestamp.

I prefer not to make an opt-out but I am open to other suggestions. For example do not do this for files located in OUT_DIR or elsewhere in the target dir, only in the current crate's manifest dir.

For example do not do this for files located in OUT_DIR

Even better, thanks for the quick reply! I opened a PR at #1668.