Add a variable use_system_xcode to GN.

build/toolchain/toolchain.gni

 # Copyright 2015 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.
 
 # Toolchain-related configuration that may be needed outside the context of the
 # toolchain() rules themselves.
 
 import("//build/config/chrome_build.gni")
 
 declare_args() {
@@ skipping 22 matching lines @@
   # the CLANG_REVISION to use, instead of the version hard-coded into
   # //tools/clang/scripts/update.py. This should only be used in
   # conjunction with setting LLVM_FORCE_HEAD_REVISION in the
   # environment when `gclient runhooks` is run as well.
   llvm_force_head_revision = false
 
   # Compile with Xcode version of clang instead of hermetic version shipped
   # with the build. Used on iOS to ship official builds (as they are built
   # with the version of clang shipped with Xcode).
   use_xcode_clang = is_ios && is_official_build
+
+  # Use the system install of Xcode for tools like ibtool, libtool, etc.
+  # This does not affect the compiler. When this variable is false, targets will
+  # instead use a hermetic install of Xcode. [The hermetic install can be
+  # obtained with gclient sync after setting the environment variable
+  # FORCE_MAC_TOOLCHAIN].
+  use_system_xcode = true
+
+  # The path to the hermetic install of Xcode. Only relevant when
+  # use_system_xcode = false.
+  hermetic_xcode_path =
+      rebase_path("//build/mac_files/Xcode.app", "", root_build_dir)

[Dirk Pranke, 2016/10/04 20:25:40]

Can we just set xcode_path to "/Applications/Xcode.app" (or whatever the
equivalent is) by default, and not need two flags?

On a related note, on windows, we configure things by calling out to a script
(vs_toolchain.py) to figure out whether to use the hermetic toolchain or a
system one, and just return the path to use, which then gets passed around as
appropriate. See build/config/win/visual_studio_version.gni for the details.

It seems like it would be good to mirror that approach here.

But we can probably also make such changes later, when we're closer to have
hermetic be on by default.

WDYT?

[erikchen, 2016/10/05 19:57:19]

I like the idea of only having a single variable that is always set. This will
also simplify a lot of the logic.

But I also want there to be a single boolean parameter that users can configure
to switch between hermetic and non-hermetic. Maybe the script should check
FORCE_MAC_TOOLCHAIN and there will be no GN parameter. But you're moving
FORCE_MAC_TOOLCHAIN into a gclient config...which seems like the wrong place to
specify this type of build configuration. Should we discuss this more when you
get back?

[Dirk Pranke, 2016/10/06 01:08:44]

Good point re: a simple flag.

We can certainly discuss more when I'm back in (likely tomorrow), and this CL
doesn't
need to be blocked on a decision either way, so two flags for now is fine.

The way I expect the gclient integration to work is that whether we pulled in
the hermetic
toolchain will affect what the default build setting is, but it won't solely
control it (i.e., you
can't build w/ the hermetic toolchain if you don't have it, but you can still
turn it off).

 }
 
 declare_args() {
   if (is_clang) {
     # Clang compiler version. Clang files are placed at version-dependent paths.
     clang_version = "4.0.0"
   }
 }
 
 # Check target_os here instead of is_ios as this file is loaded for secondary
@@ skipping 48 matching lines @@
   _tool_wrapper_path =
       rebase_path("//build/toolchain/win/tool_wrapper.py", root_build_dir)
 
   stamp_command = "$python_path $_tool_wrapper_path stamp {{output}}"
   copy_command =
       "$python_path $_tool_wrapper_path recursive-mirror {{source}} {{output}}"
 } else {
   stamp_command = "touch {{output}}"
   copy_command = "ln -f {{source}} {{output}} 2>/dev/null || (rm -rf {{output}} && cp -af {{source}} {{output}})"
 }