build.rs: rerun-if-env-changed should mean "changed compared to last execution of the same kind" (check vs build/run)

[Boscop]

Currently, it seems that build.rs scripts share the same environment when run by cargo build/cargo run and cargo check.
This is a problem which leads to unnecessary rebuilds of libsqlite3-sys whenever I have cargo watch -x run running in cmd.exe, when I then do cargo check in my editor (so that I can jump to errors/warnings easily).
This causes a rebuild of libsqlite3-sys and all its dependent crates in my workspace for every switch between cargo check and the cargo run started by cargo watch.
Because: libsqlite3-sys uses rerun-if-env-changed=PATH AND apparently cargo watch gives a different PATH to cargo run than cmd.exe has [1]. Because if I run cargo run normally (not through cargo watch) this doesn't happen.
The same happens when I run cargo run normally (not through cargo watch) but in Cmder instead of in cmd.exe, and here I know that it has a different PATH than my editor. In Sublime Text and in Cmder I ran the python command import os; os.environ['PATH'] to check, and indeed, Cmder adds some of his own folders to PATH, which is why I switched to using the bare cmd.exe (to avoid the recompilations of libsqlite3-sys and its dependent crates in my workspace, which takes several minutes every time). But in bare cmd.exe, the same unnecessary recompilations happen when using cargo watch -x run and doing cargo check in Sublime Text.

So currently, it seems that rerun-if-env-changed means, "changed, regardless of whether we also switched between check and build/run".
I suggest that rerun-if-env-changed should mean "changed compared to last execution of the same kind": If the build.rs script is currently being executed because of cargo check, compare the env var to the last time it was also executed by cargo check, NOT by cargo build.
And similarly for cargo build/run. build and run are treated the same, because run implies build. But check doesn't imply build, they also produce separate artifacts in the target dir. So in a similar vein, their env's should be kept separate with respect to rerun-if-env-changed!

[1]: Btw, it's not cargo-watch's fault that the PATH for its spawned process is different, it's cargo's: #7431

[epage]

Whats not to clear to me is why this matters as we don't tell build scripts which is being done (see #4001)

[epage]

Without more information, I'm closing in favor of #4001