Rework win_toolchains a bit and copy the vs runtime DLLs as needed.

build/config/BUILDCONFIG.gn

Index: build/config/BUILDCONFIG.gn
diff --git a/build/config/BUILDCONFIG.gn b/build/config/BUILDCONFIG.gn
index c9ec4a2f858aa7bbdbebcd01cee2e842c504c228..b01efea66e91026586f749b3c043ed0d9480b8a6 100644
--- a/build/config/BUILDCONFIG.gn
+++ b/build/config/BUILDCONFIG.gn
@@ -41,6 +41,7 @@ declare_args() {
   # Normally this would get set automatically when you specify a target using
   # the 64-bit toolchain. You can also set this on the command line to convert
   # the default toolchain to 64-bit.
+  # TODO(dpranke): Rework this.
   force_win64 = false
 
   # Selects the desired build flavor. Official builds get additional
@@ -175,6 +176,8 @@ is_desktop_linux = is_linux && !is_chromeos
 # =============================================================================
 
 if (is_win) {
+  # TODO(dpranke): Delete this? x64 should mean x64 and force_win64 should

[scottmg, 2014/11/13 03:49:59]

I agree, we should get rid of force_win64, or at least rationalize it (I don't
understand what it's supposed to mean)

[Dirk Pranke, 2014/11/13 05:49:36]

Yeah, I'm waiting for Brett's feedback, because I'm not sure why things are the
way they are, either.

[brettw, 2014/11/14 20:45:45]

Let's just delete all force_win64 stuff (including this block) and use the
current CPU arch to define the build type. When I wrote this, we didn't have
full x64 build support so there was some weirdness in that we needed to support
some, but not all of the build.

[Dirk Pranke, 2014/11/14 23:03:22]

Done.

+  # not be needed.
   # Always use 32-bit on Windows, even when compiling on a 64-bit host OS,
   # unless the override flag is specified.
   if (force_win64) {
@@ -497,9 +500,10 @@ set_defaults("test") {
 if (is_win) {
   # TODO(brettw) name the toolchains the same as cpu_arch as with Linux below
   # to eliminate these conditionals.
-  if (build_cpu_arch == "x64") {
+  # TODO(dpranke): Fix this.

[brettw, 2014/11/14 20:45:45]

I'd say we should delete my comment and your todo and just write here that on
Windows, we always use the same arch for host and target. This should make the
builds faster and I think will always work. It also doesn't prevent us from
cross-compiling for special cases.

[Dirk Pranke, 2014/11/14 23:03:21]

Done.

+  if (cpu_arch == "x64") {

[scottmg, 2014/11/13 03:49:59]

what's build_cpu_arch supposed to mean? the target that host binaries are built
for? or the bitness that the compiler is? (there's all 4 permutations of
{x86,x64}->{x86,x64} toolchains, the x86 bitness compilers are needed for
Express vs. Pro.

[Dirk Pranke, 2014/11/13 05:49:36]

cpu_arch is the architecture you're trying to build for (target). build_cpu_arch
is the architecture you're actually running on. The clearest example is in the
Android builds, where build_cpu_arch == x64 (when running on Linux using a
64-bit GN on a 64-bit kernel) and cpu_arch == arm.

GN doesn't give you a built-in way to cross-compile for a different "host"
architecture, so I think that's what Brett is attempting to do with
host_toolchain, here (so, in the other files, we depend on things like
"image_diff($host_toolchain)".

I don't understand if this complexity is really needed; another place where I
need feedback from Brett.

     host_toolchain = "//build/toolchain/win:64"
-  } else if (build_cpu_arch == "x86") {
+  } else if (cpu_arch == "x86") {
     host_toolchain = "//build/toolchain/win:32"
   }