add nacl_toolchain to //build and flip to using it in the GN build.

build/toolchain/nacl_toolchain.gni

+# Copyright (c) 2014 The Native Client Authors. All rights reserved.

[Dirk Pranke, 2015/08/28 02:29:41]

This file is copied over from
//native_client/build/toolchain/nacl_toolchain.gni, but updated w/ the parameter
names for the latest gcc_toolchain.gni.

+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+import("//build/toolchain/gcc_toolchain.gni")
+
+# This template defines a NaCl toolchain.
+#
+# The template defines both a "raw" and "cooked" toolchain.  These toolchains

[brettw, 2015/08/28 18:25:52]

I don't understand this comment, I see only one toolchain in this template
definition.

[Dirk Pranke, 2015/08/28 20:08:32]

I think this comment might be out of date. I will check and confirm.

[Dirk Pranke, 2015/08/28 20:37:07]

Confirmed. Will clean it up.

+# are identical, but use different names to allow us to inject dependencies
+# without creating circular references.
+#
+# It requires the following variables specifying the executables to run:
+#  - cc
+#  - cxx
+#  - ar
+#  - ld
+# and the following which is used in the toolchain_args
+#  - toolchain_cpu  (What "current_cpu" should be set to when invoking a
+#                    build using this toolchain.)
+
+template("nacl_toolchain") {
+  assert(defined(invoker.cc), "nacl_toolchain() must specify a \"cc\" value")
+  assert(defined(invoker.cxx), "nacl_toolchain() must specify a \"cxx\" value")
+  assert(defined(invoker.ar), "nacl_toolchain() must specify a \"ar\" value")
+  assert(defined(invoker.ld), "nacl_toolchain() must specify a \"ld\" value")
+  assert(defined(invoker.toolchain_cpu),
+         "nacl_toolchain() must specify a \"toolchain_cpu\"")
+
+  toolchain_os = "nacl"
+  if (defined(invoker.is_clang)) {

[Roland McGrath, 2015/08/28 20:58:40]

Use forward_variables_from for this, postlink, and link_outputs.
Less code to use it for cc et al too (below), and equivalent after the asserts
above.

[Dirk Pranke, 2015/08/28 21:17:05]

Ack. I debated whether to change that or not as part of this CL, but was erring
on the side
of "minimize changes to the file until after we've de-forked".

+    is_clang = invoker.is_clang
+  }
+  if (defined(invoker.executable_extension)) {
+    executable_extension = invoker.executable_extension
+  } else {
+    executable_extension = ".nexe"
+  }
+  toolchain_cpu = invoker.toolchain_cpu
+
+  cc = invoker.cc
+  cxx = invoker.cxx
+  ar = invoker.ar
+  ld = invoker.ld
+  if (defined(invoker.postlink)) {
+    postlink = invoker.postlink
+  }
+  if (defined(invoker.link_outputs)) {
+    link_outputs = invoker.link_outputs
+  }
+
+  # NaCl toolchains do not support shared libraries and so they don't support

[Roland McGrath, 2015/08/28 20:58:40]

NaCl glibc toolchains do support shared libraries.  Perhaps we don't want to
support component builds even for those, but this statement is not entirely
accurate.

[Dirk Pranke, 2015/08/28 21:17:05]

I see. I have a vague memory of ncbray telling me otherwise. I'm happy to change
to 
something else; what would you prefer?

[Roland McGrath, 2015/08/28 22:35:57]

ncbray disclaims all knowledge of this particular bit of history, and the
history shows it came from https://codereview.chromium.org/1121643002 and ncbray
was never involved!  So there.  That said, and with some latent pedanticism
addressed locally, it's fine enough to leave this as it is for now.  I think the
conclusion "we never want NaCl toolchains to build component builds" is probably
correct regardless.

+  # component_mode builds.
+  is_component_build = false
+
+  gcc_toolchain(target_name) {
+    rebuild_define = "NACL_TC_REV=" + invoker.toolchain_revision
+    if (defined(invoker.deps)) {
+      deps = invoker.deps
+    }
+  }
+}