autocfg does not work in the presence of -Z build-std

[jdm]

build.rs:

fn main() {
  assert!(autocfg::new().probe_sysroot_crate("std"));
}

cargo build works fine for any target where libstd is already distributed. cargo build --target x86_64-uwp-windows-msvc -Z build-std panics even though the sysroot is being built correctly.

[cuviper]

Does cargo communicate this in any way? Maybe an environment variable?

[jdm]

I've asked that question in https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Signalling.20the.20presence.20of.20-Z.20build-std.

[melvyn2]

This breaks the bigint crate for certain targets like i686-apple-darwin. Any idea for when this might be fixed?

[cuviper]

There's no plan how to fix it yet...

Assuming you mean num-bigint, it should degrade ok without it, no?

[melvyn2]

Some dependent crates rely on features which get deactivated because of this, even though bigint builds successfully... I'll try to build the stdlib by hand in the meantime. Hopefully -Z build-std will be stabilized eventually.

[jyn514]

Why does autocfg care if the crate is loaded from the sysroot or passed with --extern? Shouldn't extern crate std work in both cases?

[jyn514]

Oh, is the problem that cargo only passes --extern std=... to the final crate, not to build scripts? I wonder if it should set some environment variable with a list of the std crates built from source ... in general I think it would be nice for cargo to expose a way for build scripts to invoke rustc the same way cargo would in the current build.

[jyn514]

Ah, that already exists and it's called CARGO_ENCODED_RUSTFLAGS 😄 I think we should open an upstream issue for cargo to include the --extern std flags in CARGO_ENCODED_RUSTFLAGS.