mac: Make build documentation less out-of-date.

docs/mac_build_instructions.md

Index: docs/mac_build_instructions.md
diff --git a/docs/mac_build_instructions.md b/docs/mac_build_instructions.md
index 818b2e3cc743af8032797dc9fe2f47851c87e3b8..cd6f4f5a12e9fe04b7b8b38a751902bd20a55603 100644
--- a/docs/mac_build_instructions.md
+++ b/docs/mac_build_instructions.md
@@ -5,19 +5,14 @@
 ## Prerequisites
 
 *   A Mac running 10.9+.
-*   [Xcode](https://developer.apple.com/xcode) 5+.
+*   [Xcode](https://developer.apple.com/xcode) 7.3+.
 *   [depot\_tools](http://dev.chromium.org/developers/how-tos/depottools).
-*   Xcode Command Line Tools. Run
-    ```
-    xcode-select --install
-    ```
-    to install them.
 *   The OSX 10.10 SDK. Run
     ```
     ls `xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs
     ```
-    to check whether you have it. If you don't have it, you need to get one from
-    an install of Xcode 6, and place it in the above directory.
+    to check whether you have it.  Building with the 10.11 SDK works too, but
+    the releases currently use the 10.10 SDK.
 
 ## Getting the code
 
@@ -34,50 +29,52 @@ drive name, the default "Macintosh HD2" for a second drive has a space.
 
 ## Building
 
-Chromium on OS X can only be built using the [Ninja](ninja_build.md) tool and
+Chromium on OS X is built using the [Ninja](ninja_build.md) tool and
 the [Clang](clang.md) compiler. See both of those pages for further details on
 how to tune the build.
 
+Run
+
+    gn gen out/gn
+
+to generate build files (replace "gn" in "out/gn" with whatever you like), and
+then run
+
+    ninja -C out/gn chrome
+
+to build.  You can edit out/gn/args.gn to configure the build.
+
 Before you build, you may want to
 [install API keys](https://sites.google.com/a/chromium.org/dev/developers/how-tos/api-keys)
 so that Chrome-integrated Google services work. This step is optional if you
 aren't testing those features.
 
-### Raising system-wide and per-user process limits
-
-If you see errors like the following:
+## Faster builds
 
-```
-clang: error: unable to execute command: posix_spawn failed: Resource temporarily unavailable
-clang: error: clang frontend command failed due to signal (use -v to see invocation)
-```
+Full rebuilds are about the same speed in Debug and Release, but linking is a
+lot faster in Release builds.
 
-you may be running into too-low limits on the number of concurrent processes
-allowed on the machine. Check:
+Put
 
-    sysctl kern.maxproc
-    sysctl kern.maxprocperuid
+    is_debug = false
 
-You can increase them with e.g.:
+in your args.gn to do a release build.
 
-    sudo sysctl -w kern.maxproc=2500
-    sudo sysctl -w kern.maxprocperuid=2500
+Put
 
-But normally this shouldn't be necessary if you're building on 10.7 or higher.
-If you see this, check if some rogue program spawned hundreds of processes and
-kill them first.
+    is_component_build = true
 
-## Faster builds
+in your args.gn to build many small dylibs instead of a single large executable.
+This makes incremental builds much faster, at the cost of producing a binary
+that opens less quickly.  Component builds work in both debug and release.
 
-Full rebuilds are about the same speed in Debug and Release, but linking is a
-lot faster in Release builds.
+Put
 
-Run
+    symbol_level = 1
 
-    GYP_DEFINES=fastbuild=1 build/gyp_chromium
-
-to disable debug symbols altogether, this makes both full rebuilds and linking
-faster (at the cost of not getting symbolized backtraces in gdb).
+in your args.gn to disable debug symbols altogether.  This makes both full
+rebuilds and linking faster (at the cost of not getting symbolized backtraces
+in gdb).
 
 You might also want to [install ccache](ccache_mac.md) to speed up the build.
 
@@ -85,8 +82,7 @@ You might also want to [install ccache](ccache_mac.md) to speed up the build.
 
 All build output is located in the `out` directory (in the example above,
 `~/chromium/src/out`).  You can find the applications at
-`{Debug|Release}/ContentShell.app` and `{Debug|Release}/Chromium.app`, depending
-on the selected configuration.
+`gn/Content Shell.app` and `gn/Chromium.app`.
 
 ## Unit Tests
 
@@ -98,10 +94,10 @@ small subset of these is:
 *   `net_unittests` from `net/net.gyp`
 *   `url_unittests` from `url/url.gyp`
 
-When these tests are built, you will find them in the `out/{Debug|Release}`
+When these tests are built, you will find them in the `out/gn`
 directory. You can run them from the command line:
 
-    ~/chromium/src/out/Release/unit_tests
+    ~/chromium/src/out/gn/unit_tests
 
 
 ## Coding
@@ -109,12 +105,9 @@ directory. You can run them from the command line:
 According to the
 [Chromium style guide](http://dev.chromium.org/developers/coding-style) code is
 [not allowed to have whitespace on the ends of lines](https://google.github.io/styleguide/cppguide.html#Horizontal_Whitespace).
-If you edit in Xcode, know that it loves adding whitespace to the ends of lines
-which can make editing in Xcode more painful than it should be. The
-[GTM Xcode Plugin](http://code.google.com/p/google-toolbox-for-mac/downloads/list)
-adds a preference panel to Xcode that allows you to strip whitespace off of the
-ends of lines on save. Documentation on how to install it is
-[here](http://code.google.com/p/google-toolbox-for-mac/wiki/GTMXcodePlugin).
+
+Run `git cl format` after committing to your local branch and before uploading
+to clang-format your code.
 
 ## Debugging
 
@@ -122,7 +115,7 @@ Good debugging tips can be found
 [here](http://dev.chromium.org/developers/how-tos/debugging-on-os-x). If you
 would like to debug in a graphical environment, rather than using `lldb` at the
 command line, that is possible without building in Xcode. See
-[Debugging in Xcode](http://www.chromium.org/developers/debugging-on-os-x/building-with-ninja-debugging-with-xcode)
+[Debugging in Xcode](http://www.chromium.org/developers/how-tos/debugging-on-os-x/building-with-ninja-debugging-with-xcode)
 for information on how.
 
 ## Contributing
@@ -133,46 +126,25 @@ information about writing code for Chromium and contributing it.
 
 ## Using Xcode-Ninja Hybrid
 
-While using Xcode is unsupported, GYP supports a hybrid approach of using ninja
-for building, but Xcode for editing and driving compilation. Xcode can still be
-slow, but it runs fairly well even **with indexing enabled**.
+While using Xcode is unsupported, gn supports a hybrid approach of using ninja
+for building, but Xcode for editing and driving compilation.  Xcode is still
+slow, but it runs fairly well even **with indexing enabled**.  Most people
+build in the Terminal and write code with a text editor though.
 
 With hybrid builds, compilation is still handled by ninja, and can be run by the
-command line (e.g. ninja -C out/Debug chrome) or by choosing the chrome target
+command line (e.g. ninja -C out/gn chrome) or by choosing the chrome target
 in the hybrid workspace and choosing build.
 
-To use Xcode-Ninja Hybrid, set GYP\_GENERATORS like the following:
+To use Xcode-Ninja Hybrid pass --ide=xcode to `gn gen`
 
 ```shell
-export GYP_GENERATORS="ninja,xcode-ninja"
+gn gen out/gn --ide=xcode
 ```
 
-Due to the way Xcode parses ninja output paths, it's also necessary to change
-the main gyp location to anything two directories deep. Otherwise Xcode build
-output will not be clickable.
-To make this change permanent, you can edit `chromium.gyp_env` (or create it if
-it does not exists) and define GYP\_GENERATOR\_FLAGS. In general, to use hybrid
-mode, your `chromium.gyp_env` could contain the following:
-
-```json
-{
-  "GYP_GENERATORS"     : "ninja,xcode-ninja",
-  "GYP_GENERATOR_FLAGS":
-      "xcode_project_version=3.2 " +
-      "xcode_ninja_main_gyp=src/build/ninja/all.ninja.gyp",
-}
-```
-
-After, generate the project files with:
+Open it:
 
 ```shell
-gclient runhooks
-```
-
-And finally, open it:
-
-```shell
-open build/ninja/all.ninja.xcworkspace
+open out/gn/ninja/all.xcworkspace
 ```
 
 You may run into a problem where http://YES is opened as a new tab every time
@@ -182,52 +154,11 @@ Versions Browser". When this option is checked, Xcode adds
 `--NSDocumentRevisionsDebugMode YES` to the launch arguments, and the `YES` gets
 interpreted as a URL to open.
 
-If you want to limit the number of targets visible, which is known to improve
-Xcode performance, add `xcode_ninja_executable_target_pattern=%target%` where
-`%target%` is a regular expression matching executable targets you'd like to
-include.
-
-To include non-executable targets, use `xcode_ninja_target_pattern=All_iOS`.
-
 If you have problems building, join us in `#chromium` on `irc.freenode.net` and
 ask there. As mentioned above, be sure that the
 [waterfall](http://build.chromium.org/buildbot/waterfall/) is green and the tree
 is open before checking out. This will increase your chances of success.
 
-## Using Emacs as `EDITOR` for `git commit`
-
-Using the [Cocoa version of Emacs](http://emacsformacosx.com/) as the `EDITOR`
-environment variable on Mac OS will cause `git commit` to open the message in a
-window underneath all the others. To fix this, create a shell script somewhere
-(call it `$HOME/bin/EmacsEditor` in this example) containing the following:
-
-```
-#!/bin/sh
-
-# All of these hacks are needed to get "git commit" to launch a new
-# instance of Emacs on top of everything else, properly pointing to
-# the COMMIT_EDITMSG.
-
-realpath() {
-    [[ $1 = /* ]] && echo "$1" || echo "$PWD/${1#./}"
-}
-
-i=0
-full_paths=()
-for arg in "$@"
-do
-  full_paths[$i]=$(realpath $arg)
-  ((++i))
-done
-
-open -nWa /Applications/Emacs.app/Contents/MacOS/Emacs --args --no-desktop \
-    "${full_paths[@]}"
-```
-
-and in your `.bashrc` or similar,
-
-    export EDITOR=$HOME/bin/EmacsEditor
-
 ## Improving performance of `git status`
 
 `git status` is used frequently to determine the status of your checkout.  Due