Rust proxies obfuscate changes to the underlying tools when using a stat approach

Problem you are trying to solve

I'm a maintainer of the Meson build-system generator, which supports building Rust code in combination with other languages. Meson generally is used to generate ninja, and we write a dependency in the ninja for all targets of a given language to depend on their compiler binaries, so if rustc is updated, ninja will notice and mark all rust targets as out of date on its next invocation and they'll be rebuilt. This works fine when using rustc installed through traditional linux packaging, but rustup doesn't expose these binaries and instead wraps them with proxies, which themselves don't change.

Solution you'd like

As a policy, Meson cannot add always out of date targets that must be run by ninja. The difference in the amount of time a no-op build with ninja takes vs a simple "run rust and collect the version" is non trivial (the former is essentially free). But for other build systems that use make-like file stating we need a file of some kind to stat. I am not myself a rustup user, but I see that rustup can set a per-directory override, so we need to account for that as well, which makes the idea of modifying the proxy when the toolchain changes seem like a non-viable approach.

The most obvious solution to me then would be a simple text file in a well known location that contains the version of the toolchain in use, as well as one that's written to the directory when rustup overrides on a per-directory basis. When the toolchain changes the file is rewritten. I can tell ninja to watch this file as a dependency of Rust targets.

I'm fine with telling my users that if they want to switch to/from local overrides they need to manually regenerate the build rules, or at at least that would be my problem to solve in Meson, and not for rustup to solve

Notes

No response

Start by tracing rustup's proxy behavior and the handling of per-directory toolchain overrides described in this issue. Compare the available toolchain-change signals with the needs of make-like build systems, then determine the scope and update behavior for any version marker. Done should include a documented approach that handles both default and directory-specific overrides.