mk: Fix MSVC bootstrapping itself

[alexcrichton]

Now that MSVC support has landed in the most recent nightlies we can now have
MSVC bootstrap itself without going through a GNU compiler first. Unfortunately,
however, the bootstrap currently fails due to the compiler not being able to
find the llvm-ar.exe tool during the stage0 libcore compile. The compiler cannot
find this tool because it's looking inside a directory that does not exist:

$SYSROOT/rustlib/x86_64-pc-windows-gnu/bin

The gnu on this triple is because the bootstrap compiler's host architecture
is GNU. The build system, however, only arranges for the llvm-ar.exe tool to be
available in this location:

$SYSROOT/rustlib/x86_64-pc-windows-msvc/bin

To resolve this discrepancy, the build system has been modified to understand
triples that are bootstrapped from another triple, and in this case copy the
native tools to the right location.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @brson

[alexcrichton]

I have confirmed in dev that this is able to bootstrap itself!

[retep998]

Confirmed on my system as well.

[brson]

@bors r+

[bors]

📌 Commit b8c5921 has been approved by brson

[bors]

⌛ Testing commit b8c5921 with merge f141901...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

[vadimcn]

I am wondering if the right solution for this problem wouldn't be replacing host_filesearch with target_filesearch on this line.
IIRC, rustlib/<target>/bin was supposed to contain host platform's tools that can output target platform's binaries.

[alexcrichton]

That was actually my original thought as well, but after some discussion with @brson we concluded that it would probably make the most sense to not assume that the host can run the target binaries (because it's not true in most situations).

I think in the long term we want the tools we provide (in <target>/bin) to be as maximally "cross compilable" as possible. For example the llvm-ar.exe we're shipping now with MSVC is able to manage archives for all our targets (as far as I know at least), so it means that if you want to cross to an arbitrary target you can also use the tools that we ship.

[vadimcn]

I think in the long term we want the tools we provide (in <target>/bin) to be as maximally "cross compilable" as possible. For example the llvm-ar.exe we're shipping now with MSVC is able to manage archives for all our targets (as far as I know at least),

Shouldn't they live in bin then (next to rustc)?

[alexcrichton]

That has the unfortunate side effect of being installed-by-default for the entire system, which isn't perhaps always desired. For example I would be somewhat uncomfortable distributing llvm-ar to all systems' normal /bin folder.

We could perhaps but rustc in multiple locations! (it's quite small after all)