Cargo should support explicitly specifying a host target for build scripts

[staktrace]

We ran into a situation in the Mozilla build system, when doing a Windows 32-bit build (using 32-bit MozillaBuild shell) on a 64-bit Windows machine. In this situation the MozillaBuild shell has invoked vcvars.bat to set up a 32-bit build environment, but cargo still tries to do a 64-bit build for build scripts. This results in failure.

More context in bug 1350001. I'm filing this bug as a result of comment 9 in that thread, by @alexcrichton. Specifically:

Cargo could support explicitly specifying a host target (or build target I guess is the autotools name) where it "cross compiles" build scripts.

Although we fixed bug 1350001 by running cargo build in a "clean" environment (with env vars stripped out) that is not ideal and caused other breakages (such as bug 1355464). Fixing this in cargo would be a better solution.

[alexcrichton]

Note that a key aspect here is that the host toolchain was 64-bit. Cargo didn't detect 64-bit or anything like that, it just didn't pass --target which caused the host toolchain to attempt to produce 64-bit binaries, failing b/c vcvars env vars were pointing to the 32-bit link.exe toolchain.

This would likely look like a --host argument to Cargo, if implemented, but this may be somewhat nontrivial to do so in the backend.

[upsuper]

Cargo should probably determine from the environment about what target should be used for build script, or probably just special case 32bit Windows: because you need linker anyway, and in a given PATH there is only one linker, so probably it is better building the build script in the same target in target platform rather than host platform if both are Windows.

[upsuper]

MSVC has a toolchain with 32bit host and 64bit target, and in that case the strategy may not work, because 32bit Windows cannot run 64bit executable. But I wonder whether anyone would actually do that in practice...

[froydnj]

Ran into a similar situation last week where specifying an explicit CARGO_TARGET_X86_64_APPLE_DARWIN_LINKER environment variable with a cargo build --target invocation wound up getting that same linker used during host compilations for build scripts. I think this bug is basically the same, but feel free to say otherwise and I can separate out that behavior into a different bug.

The current behavior is certainly convenient in some scenarios, but I think drawing a stronger line between host configuration and target configuration would be a good idea.

[alexcrichton]

@froydnj were you compiling for x86_64-apple-darwin from x86_64-apple-darwin? If so, I don't think this bug would solve that problem because you basically want those linker flags to go to target artifacts, not "host" artifacts, or build scripts basically.

Can you also clarify what flags were causing problems?

[froydnj]

@alexcrichton I was compiling for host == target, yes. Whether this bug would solve the problem depends on what got implemented; if this bug wound up with some sort of --host flag passed along somewhere such that CARGO_TARGET_* variables and related were not consulted for compiling host-y things like build scripts, I think that would solve the problem.