Remove GYP support from MB.

This is a long-overdue change that removes all of the code
from //tools/mb for invoking GYP instead of GN. This also
updates the docs to remove most of the references to GYP.
The docs can probably be updated even more to talk about
other things that have been added, but I'll leave that
for a separate CL.

R=jbudorick@chromium.org

Change-Id: Ic03c43189ec6fe0cc567d84480a27bc969a4477d
Reviewed-on: https://chromium-review.googlesource.com/825586Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523978}

tools/mb/README.md

 # MB - The Meta-Build wrapper
 
-MB is a simple wrapper intended to provide a uniform interface to either
-GYP or GN, such that users and bots can call one script and not need to
-worry about whether a given bot is meant to use GN or GYP.
+MB is a simple wrapper around the GN build tool.
+
+It was originally written as part of the GYP->GN migration, in order to
+provide a uniform interface to either GYP or GN, such that users and bots
+can call one script and not need to worry about whether a given bot was
+meant to use GN or GYP.
+
+It eventually grew additional functionality and is now still used even
+though everything is GN-only.
 
 It supports two main functions:
 
-1. "gen" - the main `gyp_chromium` / `gn gen` invocation that generates the
-   Ninja files needed for the build.
+1. "gen" - the main `gn gen` invocation that generates the Ninja files
+   needed for the build.
 
 2. "analyze" - the step that takes a list of modified files and a list of
    desired targets and reports which targets will need to be rebuilt.

tools/mb/docs/design_spec.md

@@ -4,21 +4,22 @@
 
 ## Intro
 
-MB is intended to address two major aspects of the GYP -> GN transition
-for Chromium:
+MB was originally intended to address two major aspects of the GYP -> GN
+transition for Chromium:
 
 1. "bot toggling" - make it so that we can easily flip a given bot
    back and forth between GN and GYP.
 
 2. "bot configuration" - provide a single source of truth for all of
-   the different configurations (os/arch/`gyp_define` combinations) of
+   the different configurations (os/arch/`gn_args` combinations) of
    Chromium that are supported.
 
-MB must handle at least the `gen` and `analyze` steps on the bots, i.e.,
-we need to wrap both the `gyp_chromium` invocation to generate the
-Ninja files, and the `analyze` step that takes a list of modified files
-and a list of targets to build and returns which targets are affected by
-the files.
+Now that everything is using GN, only the second purpose is really relevant,
+but it's still important. MB must handle at least the `gen` and `analyze`
+steps on the bots, i.e., we need to wrap both the `gn gen` invocation to
+generate the Ninja files, and the `analyze` step that takes a list of
+modified files and a list of targets to build and returns which targets
+are affected by the files.
 
 For more information on how to actually use MB, see
 [the user guide](user_guide.md).
@@ -26,7 +27,7 @@ For more information on how to actually use MB, see
 ## Design
 
 MB is intended to be as simple as possible, and to defer as much work as
-possible to GN or GYP. It should live as a very simple Python wrapper
+possible to GN. It should live as a very simple Python wrapper
 that offers little in the way of surprises.
 
 ### Command line
@@ -40,16 +41,12 @@ It is structured as a single binary that supports a list of subcommands:
 
 `mb` will first look for a bot config file in a set of different locations
 (initially just in //ios/build/bots). Bot config files are JSON files that
-contain keys for 'GYP_DEFINES' (a list of strings that will be joined together
-with spaces and passed to GYP, or a dict that will be similarly converted),
-'gn_args' (a list of strings that will be joined together), and an
-'mb_type' field that says whether to use GN or GYP. Bot config files
-require the full list of settings to be given explicitly.
+contain keys for 'gn_args' (a list of strings that will be joined together).
+Bot config files require the full list of settings to be given explicitly.
 
 If no matching bot config file is found, `mb` looks in the
-`//tools/mb/mb_config.pyl` config file to determine whether to use GYP or GN
-for a particular build directory, and what set of flags (`GYP_DEFINES` or `gn
-args`) to use.
+`//tools/mb/mb_config.pyl` config file to determine what set of flags
+(`gn args`) to use.
 
 A config can either be specified directly (useful for testing) or by specifying
 the master name and builder name (useful on the bots so that they do not need
@@ -64,10 +61,6 @@ The interface to `mb analyze` is described in the
 
 The way analyze works can be subtle and complicated (see below).
 
-Since the interface basically mirrors the way the "analyze" step on the bots
-invokes `gyp_chromium` today, when the config is found to be a gyp config,
-the arguments are passed straight through.
-
 It implements the equivalent functionality in GN by calling `gn refs
 [list of files] --type=executable --all --as=output` and filtering the
 output to match the list of targets.
@@ -110,16 +103,15 @@ So:
    you need to build base_unittests. For others (like the telemetry and
    layout tests), you might need to build several executables in order to
    run the tests, and that mapping might best be captured by a *meta*
-   target (a GN group or a GYP 'none' target like `webkit_tests`) that
-   depends on the right list of files. Because the GN and GYP files know
-   nothing about test steps, we have to have some way of mapping back
-   and forth between test steps and build targets. That mapping
-   is *not* currently available to MB (or GN or GYP), and so we have to 
-   enough information to make it possible for the caller to do the mapping.
+   target (a GN group like `webkit_tests`) that depends on the right list
+   of files. Because the BUILD.gn files know nothing about test steps, we
+   have to have some way of mapping back and forth between test steps and
+   build targets. That mapping is *not* currently available to MB (or GN),
+   and so we have to provide enough information to make it possible for
+   the caller to do the mapping.
 
 3. We might also want to know when test targets are affected by data files
    that aren't compiled (python scripts, or the layout tests themselves).
-   There's no good way to do this in GYP, but GN supports this.
 
 4. We also want to ensure that particular targets still compile even if they
    are not actually tested; consider testing the installers themselves, or
@@ -137,9 +129,9 @@ So:
 6. As noted above, in the ideal case we actually have enough resources and
    things are fast enough that we can afford to build everything affected by a
    patch, but listing every possible target explicitly would be painful. The
-   GYP and GN Ninja generators provide an 'all' target that captures (nearly,
+   GN Ninja generator provides an 'all' target that captures (nearly,
    see [crbug.com/503241](crbug.com/503241)) everything, but unfortunately
-   neither GN nor GYP actually represents 'all' as a meta target in the build
+   GN doesn't actually represent 'all' as a meta target in the build
    graph, so we will need to write code to handle that specially.
 
 7. In some cases, we will not be able to correctly analyze the build graph to
@@ -216,7 +208,7 @@ In the output case, an empty list indicates that there was nothing to
 build, or that there were no affected test targets as appropriate.
 
 Note that passing no arguments to Ninja is equivalent to passing
-`all` to Ninja (at least given how GN and GYP work); however, we
+`all` to Ninja (at least given how GN works); however, we
 don't want to take advantage of this in most cases because we don't
 actually want to build every out of date target, only the targets
 potentially affected by the files. One could try to indicate
@@ -225,7 +217,7 @@ list, but using the existing fields for this seems fragile and/or
 confusing, and adding a new field for this seems unwarranted at this time.
 
 There is an "error" field in case something goes wrong (like the
-empty file list case, above, or an internal error in MB/GYP/GN). The
+empty file list case, above, or an internal error in MB/GN). The
 analyze code should also return an error code to the shell if appropriate
 to indicate that the command failed.
 
@@ -350,8 +342,7 @@ it is ...
 
 The first issue is whether or not this should exist as a script in
 Chromium at all; an alternative would be to simply change the bot
-configurations to know whether to use GYP or GN, and which flags to
-pass.
+configurations to know which flags to pass.
 
 That would certainly work, but experience over the past two years
 suggests a few things:
@@ -373,23 +364,12 @@ be a simple one, hiding as much of the chromium logic as possible.
 ### Why not have MB be smarter about de-duping flags?
 
 This just adds complexity to the MB implementation, and duplicates logic
-that GYP and GN already have to support anyway; in particular, it might
-require MB to know how to parse GYP and GN values. The belief is that
+that GN already has to support anyway; in particular, it might
+require MB to know how to parse GN values. The belief is that
 if MB does *not* do this, it will lead to fewer surprises.
 
 It will not be hard to change this if need be.
 
-### Integration w/ gclient runhooks
-
-On the bots, we will disable `gyp_chromium` as part of runhooks (using
-`GYP_CHROMIUM_NO_ACTION=1`), so that mb shows up as a separate step.
-
-At the moment, we expect most developers to either continue to use
-`gyp_chromium` in runhooks or to disable at as above if they have no
-use for GYP at all. We may revisit how this works once we encourage more
-people to use GN full-time (i.e., we might take `gyp_chromium` out of
-runhooks altogether).
-
 ### Config per flag set or config per (os/arch/flag set)?
 
 Currently, mb_config.pyl does not specify the host_os, target_os, host_cpu, or
@@ -410,17 +390,15 @@ config file change, however.
 
 ### Non-goals
 
-* MB is not intended to replace direct invocation of GN or GYP for
+* MB is not intended to replace direct invocation of GN for
   complicated build scenarios (a.k.a. Chrome OS), where multiple flags need
   to be set to user-defined paths for specific toolchains (e.g., where
   Chrome OS needs to specify specific board types and compilers).
 
 * MB is not intended at this time to be something developers use frequently,
-  or to add a lot of features to. We hope to be able to get rid of it once
-  the GYP->GN migration is done, and so we should not add things for
-  developers that can't easily be added to GN itself.
+  or to add a lot of features to. We hope to be able to get rid of it
+  eventually.
 
 * MB is not intended to replace the
-  [CR tool](https://code.google.com/p/chromium/wiki/CRUserManual). Not
-  only is it only intended to replace the gyp\_chromium part of `'gclient
-  runhooks'`, it is not really meant as a developer-facing tool.
+  [CR tool](https://code.google.com/p/chromium/wiki/CRUserManual), and
+  it is not really meant as a developer-facing tool.

tools/mb/docs/user_guide.md

@@ -4,8 +4,8 @@
 
 ## Introduction
 
-`mb` is a simple python wrapper around the GYP and GN meta-build tools to
-be used as part of the GYP->GN migration.
+`mb` is a simple python wrapper GN meta-build tool; it was originally
+written as part of the GYP->GN migration.
 
 It is intended to be used by bots to make it easier to manage the configuration
 each bot builds (i.e., the configurations can be changed from chromium
@@ -45,7 +45,7 @@ a single object with the following fields:
     reflect the stuff we might want to build *in addition to* the list
     passed in `test_targets`. Targets in this list will be treated 
     specially, in the following way: if a given target is a "meta"
-    (GN: group, GYP: none) target like 'blink_tests' or or even the
+    (GN: group) target like 'blink_tests' or or even the
     ninja-specific 'all' target, then only the *dependencies* of the
     target that are affected by the modified files will be rebuilt
     (not the target itself, which might also cause unaffected dependencies
@@ -93,18 +93,11 @@ differences can be subtle.  We won't even go into how the `targets` and
 The `-b/--builder`, `-c/--config`, `-f/--config-file`, `-m/--master`,
 `-q/--quiet`, and `-v/--verbose` flags work as documented for `mb gen`.
 
-### `mb audit`
-
-`mb audit` is used to track the progress of the GYP->GN migration. You can
-use it to check a single master, or all the masters we care about. See
-`mb help audit` for more details (most people are not expected to care about
-this).
-
 ### `mb gen`
 
-`mb gen` is responsible for generating the Ninja files by invoking either GYP
-or GN as appropriate. It takes arguments to specify a build config and
-a directory, then runs GYP or GN as appropriate:
+`mb gen` is responsible for generating the Ninja files by invoking GN with
+the right sets of build args for the given bot. It takes arguments to
+specify a build config and a directory, then runs GN as appropriate:
 
 ```
 % mb gen -m tryserver.chromium.linux -b linux_rel //out/Release
@@ -133,12 +126,7 @@ that are read and written, and all the commands that are run.
 
 If the build config will use the Goma distributed-build system, you can pass
 the path to your Goma client in the `-g/--goma-dir` flag, and it will be
-incorporated into the appropriate flags for GYP or GN as needed.
-
-If gen ends up using GYP, the path must have a valid GYP configuration as the
-last component of the path (i.e., specify `//out/Release_x64`, not `//out`).
-The gyp script defaults to `//build/gyp_chromium`, but can be overridden with
-the `--gyp-script` flag, e.g. `--gyp-script=gypfiles/gyp_v8`.
+incorporated into the appropriate flags for GN as needed.
 
 ### `mb help`
 
@@ -186,7 +174,7 @@ push origin HEAD:refs/for/refs/meta/config` to upload the CL for review.
 
 `mb gen` is also responsible for generating the `.isolate` and
 `.isolated.gen.json` files needed to run test executables through swarming
-in a GN build (in a GYP build, this is done as part of the compile step).
+in a GN build.
 
 If you wish to generate the isolate files, pass `mb gen` the
 `--swarming-targets-file` command line argument; that arg should be a path
@@ -210,7 +198,7 @@ The `mb_config.pyl` config file is intended to enumerate all of the
 supported build configurations for Chromium. Generally speaking, you
 should never need to (or want to) build a configuration that isn't
 listed here, and so by using the configs in this file you can avoid
-having to juggle long lists of GYP_DEFINES and gn args by hand.
+having to juggle long lists of gn args by hand.
 
 `mb_config.pyl` is structured as a file containing a single PYthon Literal
 expression: a dictionary with three main keys, `masters`, `configs` and
@@ -239,49 +227,38 @@ value of the `mixins` key.
 Each mixin value is itself a dictionary that contains one or more of the
 following keys:
 
-  * `gyp_crosscompile`: a boolean; if true, GYP_CROSSCOMPILE=1 is set in
-    the environment and passed to GYP.
-  * `gyp_defines`: a string containing a list of GYP_DEFINES.
   * `gn_args`: a string containing a list of values passed to gn --args.
   * `mixins`: a list of other mixins that should be included.
-  * `type`: a string with either the value `gyp` or `gn`;
-    setting this indicates which meta-build tool to use.
 
 When `mb gen` or `mb analyze` executes, it takes a config name, looks it
 up in the 'configs' dict, and then does a left-to-right expansion of the
-mixins; gyp_defines and gn_args values are concatenated, and the type values
-override each other.
+mixins; gn_args values are concatenated.
 
 For example, if you had:
 
 ```
 {
   'configs`: {
-    'linux_release_trybot': ['gyp_release', 'trybot'],
+    'linux_release_trybot': ['gn_release', 'trybot'],
     'gn_shared_debug': None,
   }
   'mixins': {
     'bot': {
-      'gyp_defines': 'use_goma=1 dcheck_always_on=0',
       'gn_args': 'use_goma=true dcheck_always_on=false',
     },
     'debug': {
       'gn_args': 'is_debug=true',
     },
-    'gn': {'type': 'gn'},
-    'gyp_release': {
+    'gn_release': {
       'mixins': ['release'],
-      'type': 'gyp',
     },
     'release': {
       'gn_args': 'is_debug=false',
     }
     'shared': {
       'gn_args': 'is_component_build=true',
-      'gyp_defines': 'component=shared_library',
     },
     'trybot': {
-      'gyp_defines': 'dcheck_always_on=1',
       'gn_args': 'dcheck_always_on=true',
     }
   }
@@ -289,11 +266,10 @@ For example, if you had:
 ```
 
 and you ran `mb gen -c linux_release_trybot //out/Release`, it would
-translate into a call to `gyp_chromium -G Release` with `GYP_DEFINES` set to
-`"use_goma=true dcheck_always_on=false dcheck_always_on=true"`.
+translate into a call to `gn --args="use_goma=true dcheck_always_on=false dcheck_always_on=true"`.
 
 (From that you can see that mb is intentionally dumb and does not
-attempt to de-dup the flags, it lets gyp do that).
+attempt to de-dup the flags, it lets GN do that).
 
 ## Debugging MB