Invoke rustc to get target information?

[madsmtm]

In #1413, I implemented parsing of rustc's target triples to get access to target_arch, target_vendor, target_os, target_env and target_abi.

But maybe we should, when outside a build script, instead invoke $RUSTC --print cfg --target $TARGET? (And invoke with --print llvm-tuple if rust-lang/compiler-team#846 lands, or --print deployment-target to fix rust-lang/rust#136113).

There's a performance cost to that, though it's probably not a big deal, we're already spawning the C compiler multiple times to check flags etc.

A bigger problem is that it means you can no longer use cc-rs in contexts where rustc isn't available!

Consider an application that did something like:

// build.rs
fn main() {
    println!("cargo::rustc-env=TARGET={}", std::env::var("TARGET").unwrap());
}

// main.rs
fn main() {
    cc::Build()
        .target(env!("TARGET"))
        .file(std::env::args().next().unwrap())
        .compile(...);
}

Such a binary could be shipped to users, but it would now require not just a C compiler, but also the Rust compiler to be available.

Perhaps that's rare, and we shouldn't support it? But that also does seem unfortunate.

(A solution in this case could be to allow omitting .target, and let that mean "compile for the host when outside build.rs". But what if the user specified .target("my-embedded-target") because they were building an application like the Arduino IDE?).

(Another solution would be to allow specifying the details with .target_arch, .target_os, .target_env etc. But that seems very verbose).

Related: rust-lang/compiler-team#850.

[NobodyXu]

A bigger problem is that it means you can no longer use cc-rs in contexts where rustc isn't available

Yeah I think it might break some users...

I can't think of any sane way to fix that