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

build/config/BUILDCONFIG.gn

 # Copyright (c) 2013 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # =============================================================================
 # BUILD FLAGS
 # =============================================================================
 #
 # This block lists input arguments to the build, along with their default
 # values. GN requires listing them explicitly so it can validate input and have
@@ skipping 23 matching lines @@
   # to configure warnings.
   is_clang = (os == "mac" || os == "ios" || os == "linux" || os == "chromeos")
 
   # Forces a 64-bit build on Windows. Does nothing on other platforms. Normally
   # we build 32-bit on Windows regardless of the current host OS bit depth.
   # Setting this flag will override this logic and generate 64-bit toolchains.
   #
   # 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
   # processing to prepare for release. Normally you will want to develop and
   # test with this flag off.
   is_official_build = false
 
   # Select the desired branding flavor. False means normal Chromium branding,
   # true means official Google Chrome branding (requires extra Google-internal
   # resources).
@@ skipping 114 matching lines @@
   is_win = false
 }
 
 is_desktop_linux = is_linux && !is_chromeos
 
 # =============================================================================
 # CPU ARCHITECTURE
 # =============================================================================
 
 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) {
     cpu_arch = "x64"
   } else {
     cpu_arch = "x86"
   }
 }
 
 if (is_android) {
@@ skipping 302 matching lines @@
 # ==============================================================================
 #
 # Here we set the default toolchain, as well as the variable host_toolchain
 # which will identify the toolchain corresponding to the local system when
 # doing cross-compiles. When not cross-compiling, this will be the same as the
 # default toolchain.
 
 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"
   }
 
   if (cpu_arch == "x64") {
     set_default_toolchain("//build/toolchain/win:64")
   } else if (cpu_arch == "x86") {
     set_default_toolchain("//build/toolchain/win:32")
   }
 } else if (is_android) {
   # Use clang for the x86/64 Linux host builds.
@@ skipping 203 matching lines @@
       if (defined(invoker.output_extension)) { output_extension = invoker.output_extension }
       if (defined(invoker.output_name)) { output_name = invoker.output_name }
       if (defined(invoker.public)) { public = invoker.public }
       if (defined(invoker.public_configs)) { public_configs = invoker.public_configs }
       if (defined(invoker.public_deps)) { public_deps = invoker.public_deps }
       if (defined(invoker.sources)) { sources = invoker.sources }
       if (defined(invoker.visibility)) { visibility = invoker.visibility }
     }
   }
 }