build.rs probe fails to propagate --target and does not use RUSTC_WRAPPER

[RalfJung]

In tricky build situations, such as when bootstrapping rustc or for cross-compilation, it is crucial to set the right --target argument for rustc invocations. The build.rs script of eyre doesn't do that, and I think that's why I am now getting build failures in eyre inside a rustc bootstrap situation:

error[E0407]: method `backtrace` is not a member of trait `StdError`
   --> /home/r/.cargo/registry/src/github.com-1ecc6299db9ec823/eyre-0.6.8/src/context.rs:147:5
    |
147 | /     fn backtrace(&self) -> Option<&Backtrace> {
148 | |         self.error.backtrace()
149 | |     }
    | |_____^ not a member of trait `StdError`

Basically, I think eyre needs the same patch as dtolnay/anyhow#249.
(FWIW autocfg gets all this right, but it seems a lot of crates re-implement the autocfg logic -- incorrectly.)

[RalfJung]

There are also other issues with this build probe:

• it doesn't propagate CARGO_ENCODED_RUSTFLAGS, and hence will fail when -Zallow-features is used.
• it doesn't respect RUSTC_WRAPPER, though I am not sure if that actually causes trouble (the wrapper could add -Zallow-features, I guess, or switch to a totally different compiler).

[RalfJung]

Due to rust-lang/rust-analyzer#12973 I would currently advise against honoring RUSTC_WRAPPER.

[thenorili]

I'll fold this into my active work on the compile probe, thanks for the concern!

[RalfJung]

Note that rust-lang/rust-analyzer#12973 has been fixed by now. The anyhow probe is probably a good template to follow.

[thenorili]

I'm already copying over their probe in the pr where i get backtrace working again : )

[RalfJung]

eyre not honoring RUSTC_WRAPPER is now blocking improvements in Miri (rust-lang/miri#3411). Miri would really like to rely on all rustc invocations going through the wrapper, it is very hard to support build scripts that bypass this. (We currently have some hacks to make that work but it's not holding together well.)

Writing build probes is not easy, there are a lot of flags and corner cases one has to worry about. It is easy to get the "general" case to work, but making it work in more exotic circumstances (e.g. when interpreting a crate using Miri for a different target) is tricky. Unfortunately everyone hand-rolls their own build probe logic so people caring about those more exotic circumstances have to file countless PRs and issues to fix the same oversights over and over again, which is tiring.

autocfg has a very well-tested build probe logic, and provides a single place to fix issues for exotic configurations, should they arise. @thenorili I wonder if you would be open to taking autocfg as a dependency, if cuviper/autocfg#24 would get resolved and you could access its build probe logic? @cuviper would you be willing to expose support for custom probes from autocfg, given a clear usecase like this one?

[ten3roberts]

Thank you for bringing this to attention.

We debated last week about trying autocfg, as I've used it before with success.

I'll see if I can push out a branch that uses autocfg for nightly backtraces etc

[ten3roberts]

Regarding the open issues you mentioned on autocfg, as well as cuviper/autocfg#43 we are not able to detect using just autocfg if we have backtraces or nightly available.

My idea is to use RUSTCFLAGS and add a eyre-unstable-backtrace etc for the nightly features, similarly to how wgpu does with with WebGPU using web-sys https://rustwasm.github.io/wasm-bindgen/web-sys/unstable-apis.html

[RalfJung]

Regarding the open issues, as well as cuviper/autocfg#43 we are not able to detect using just autocfg if we have backtraces or nightly available.

That's why I mentioned cuviper/autocfg#24. autocfg could expose its underlying build probe functionality to let you write an arbitrary piece of Rust code that will then be tested for whether it compiles.

[cuviper]

Regarding the open issues, as well as cuviper/autocfg#43 we are not able to detect using just autocfg if we have backtraces or nightly available.

That's why I mentioned cuviper/autocfg#24. autocfg could expose its underlying build probe functionality to let you write an arbitrary piece of Rust code that will then be tested for whether it compiles.

I have cuviper/autocfg#59 up for that -- please let me know if that will work for you!