Rebuild automatically if the rustc version changes

[LingMan]

Describe the bug
After a rustc version update running ninja showed this error from rustc:

error[E0514]: found crate `rusticl_opencl_gen` compiled by an incompatible version of rustc
  --> ../src/gallium/frontends/rusticl/api/context.rs:10:5
   |
10 | use rusticl_opencl_gen::*;
   |     ^^^^^^^^^^^^^^^^^^
   |
   = help: please recompile that crate using this compiler (rustc 1.63.0 (4b91a6ea7 2022-08-08)) (consider running `cargo clean` first)
   = note: the following crate versions were found:
           crate `rusticl_opencl_gen` compiled by rustc 1.62.1 (e092d0b6b 2022-07-16): /home/laughingman/git/rusticl/mesa/target/src/gallium/frontends/rusticl/librusticl_opencl_gen.rlib

To Reproduce

• Clone the rusticl/wip branch from https://gitlab.freedesktop.org/karolherbst/mesa/-/tree/rusticl/wip
• Enable -Dgallium-rusticl=true -Dopencl-spirv=true -Dshader-cache=true -Dllvm=true -Drust_std=2021
• Build with ninja
• Change your rustc version. In my case I updated from 1.62 to 1.63.
• Build with ninja again.

Expected behavior
Rebuilds should happen automatically as needed.

system parameters

• Is this a cross build or just a plain native build (for the same computer)?
  Native
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)
  Manjaro Linux
• what Python version are you using e.g. 3.8.0
  3.10.5
• what meson --version
  0.63.99 (self-compiled version from this PR)
• what ninja --version if it's a Ninja build
  1.11.0

cc @dcbaker

[tristan957]

There is a similar issue with Java in that if the JDK updates from underneath you, the realpath of javac changed, unless you specified your JAVA_HOME prior to meson setup.

I don't really think there is an easy solution to this. What if I wanted to use the 1.62 compiler? I don't think it makes sense to suddenly reconfigure automatically.

[LingMan]

So, I'm using rustup to install the rust toolchain. It can install multiple toolchains side-by-side without issue and set one as default. My default is "stable" and since I have several toolchains installed the meson rust module clearly picked that default up. Had I explicitly installed 1.62, rustup would not have replaced it.

cargo shows an error if I try to build with a non-installed toolchain, but will automatically rebuild if the underlying version of an installed toolchain changed.

$cargo +1.62 build
error: toolchain '1.62-x86_64-unknown-linux-gnu' is not installed
$cargo +stable build
(compiles as needed)

[LingMan]

Oh, and note that

$ cargo +1.63 build
error: toolchain '1.63-x86_64-unknown-linux-gnu' is not installed

even though stable is currently at version 1.63.

[tristan957]

I think you can solve this by setting RUSTC=$RUSTUP_HOME/..../rustc specifically. Instead of letting meson pick up rsutc from PATH/

[LingMan]

But it picks the right rustc. I want to compile with stable. It should just recompile if the underlying version of stable changes.

[tristan957]

You can set that yourself.

RUSTC=path/to/stable/bin/rustc or whatever

[LingMan]

But that part already works. It's rustc throwing an error because it detected that the dependencies have been built with a different version.

[tristan957]

Oh. I thought this was an issue with a file no longer existing. Why can't rustc detect that and recompile? Like rustc already knows per the compiler error, so just re-compile. I do have a better understanding of the problem now though.

[tristan957]

I guess maybe this is a ninja dependency issue and not a rustc issue?

[tristan957]

Are these separate crates?

[LingMan]

Should be but tbh it's not my code and this is my first time looking at a meson.build.

[tristan957]

If they are separate crates, then I can understand the issue, and your point is valid. Thanks for clarifying.

[eli-schwartz]

Compilers changing their version may or may not mean something. For rust particularly, it means something because there is no ABI stability.

The question is:

• how to detect it? We could add a file dependency on rustc, but that won't work due to the terrible concept of rustup, which means that rustc isn't actually rustc.
• and what to do about it? Should we force a reconfigure, or just mark all built objects as out of date?

[eli-schwartz]

Oh. I thought this was an issue with a file no longer existing. Why can't rustc detect that and recompile? Like rustc already knows per the compiler error, so just re-compile.

The problem is that rustc is being told to compile a different object altogether, not the one that it is complaining about. One build rule cannot throw an erroring return status and thereby indicate "you need to go rebuild all these other build rules before I can proceed".