diff --git a/docs/reference.md b/docs/reference.md
new file mode 100644
index 0000000..902adc0
--- /dev/null
+++ b/docs/reference.md
@@ -0,0 +1,6380 @@
+# GN Reference
+
+*This page is automatically generated from* `gn help --markdown all`.
+
+## Contents
+
+*   [Commands](#commands)
+    *   [analyze: Analyze which targets are affected by a list of files.](#analyze)
+    *   [args: Display or configure arguments declared by the build.](#args)
+    *   [check: Check header dependencies.](#check)
+    *   [clean: Cleans the output directory.](#clean)
+    *   [desc: Show lots of insightful information about a target or config.](#desc)
+    *   [format: Format .gn file.](#format)
+    *   [gen: Generate ninja files.](#gen)
+    *   [help: Does what you think.](#help)
+    *   [ls: List matching targets.](#ls)
+    *   [path: Find paths between two targets.](#path)
+    *   [refs: Find stuff referencing a target or file.](#refs)
+*   [Target declarations](#targets)
+    *   [action: Declare a target that runs a script a single time.](#action)
+    *   [action_foreach: Declare a target that runs a script over a set of files.](#action_foreach)
+    *   [bundle_data: [iOS/macOS] Declare a target without output.](#bundle_data)
+    *   [copy: Declare a target that copies files.](#copy)
+    *   [create_bundle: [iOS/macOS] Build an iOS or macOS bundle.](#create_bundle)
+    *   [executable: Declare an executable target.](#executable)
+    *   [group: Declare a named group of targets.](#group)
+    *   [loadable_module: Declare a loadable module target.](#loadable_module)
+    *   [shared_library: Declare a shared library target.](#shared_library)
+    *   [source_set: Declare a source set target.](#source_set)
+    *   [static_library: Declare a static library target.](#static_library)
+    *   [target: Declare an target with the given programmatic type.](#target)
+*   [Buildfile functions](#functions)
+    *   [assert: Assert an expression is true at generation time.](#assert)
+    *   [config: Defines a configuration object.](#config)
+    *   [declare_args: Declare build arguments.](#declare_args)
+    *   [defined: Returns whether an identifier is defined.](#defined)
+    *   [exec_script: Synchronously run a script and return the output.](#exec_script)
+    *   [foreach: Iterate over a list.](#foreach)
+    *   [forward_variables_from: Copies variables from a different scope.](#forward_variables_from)
+    *   [get_label_info: Get an attribute from a target's label.](#get_label_info)
+    *   [get_path_info: Extract parts of a file or directory name.](#get_path_info)
+    *   [get_target_outputs: [file list] Get the list of outputs from a target.](#get_target_outputs)
+    *   [getenv: Get an environment variable.](#getenv)
+    *   [import: Import a file into the current scope.](#import)
+    *   [not_needed: Mark variables from scope as not needed.](#not_needed)
+    *   [pool: Defines a pool object.](#pool)
+    *   [print: Prints to the console.](#print)
+    *   [process_file_template: Do template expansion over a list of files.](#process_file_template)
+    *   [read_file: Read a file into a variable.](#read_file)
+    *   [rebase_path: Rebase a file or directory to another location.](#rebase_path)
+    *   [set_default_toolchain: Sets the default toolchain name.](#set_default_toolchain)
+    *   [set_defaults: Set default values for a target type.](#set_defaults)
+    *   [set_sources_assignment_filter: Set a pattern to filter source files.](#set_sources_assignment_filter)
+    *   [split_list: Splits a list into N different sub-lists.](#split_list)
+    *   [template: Define a template rule.](#template)
+    *   [tool: Specify arguments to a toolchain tool.](#tool)
+    *   [toolchain: Defines a toolchain.](#toolchain)
+    *   [write_file: Write a file to disk.](#write_file)
+*   [Built-in predefined variables](#predefined_variables)
+    *   [current_cpu: [string] The processor architecture of the current toolchain.](#current_cpu)
+    *   [current_os: [string] The operating system of the current toolchain.](#current_os)
+    *   [current_toolchain: [string] Label of the current toolchain.](#current_toolchain)
+    *   [default_toolchain: [string] Label of the default toolchain.](#default_toolchain)
+    *   [host_cpu: [string] The processor architecture that GN is running on.](#host_cpu)
+    *   [host_os: [string] The operating system that GN is running on.](#host_os)
+    *   [invoker: [string] The invoking scope inside a template.](#invoker)
+    *   [python_path: [string] Absolute path of Python.](#python_path)
+    *   [root_build_dir: [string] Directory where build commands are run.](#root_build_dir)
+    *   [root_gen_dir: [string] Directory for the toolchain's generated files.](#root_gen_dir)
+    *   [root_out_dir: [string] Root directory for toolchain output files.](#root_out_dir)
+    *   [target_cpu: [string] The desired cpu architecture for the build.](#target_cpu)
+    *   [target_gen_dir: [string] Directory for a target's generated files.](#target_gen_dir)
+    *   [target_name: [string] The name of the current target.](#target_name)
+    *   [target_os: [string] The desired operating system for the build.](#target_os)
+    *   [target_out_dir: [string] Directory for target output files.](#target_out_dir)
+*   [Variables you set in targets](#target_variables)
+    *   [all_dependent_configs: [label list] Configs to be forced on dependents.](#all_dependent_configs)
+    *   [allow_circular_includes_from: [label list] Permit includes from deps.](#allow_circular_includes_from)
+    *   [arflags: [string list] Arguments passed to static_library archiver.](#arflags)
+    *   [args: [string list] Arguments passed to an action.](#args)
+    *   [asmflags: [string list] Flags passed to the assembler.](#asmflags)
+    *   [assert_no_deps: [label pattern list] Ensure no deps on these targets.](#assert_no_deps)
+    *   [bundle_contents_dir: Expansion of {{bundle_contents_dir}} in create_bundle.](#bundle_contents_dir)
+    *   [bundle_deps_filter: [label list] A list of labels that are filtered out.](#bundle_deps_filter)
+    *   [bundle_executable_dir: Expansion of {{bundle_executable_dir}} in create_bundle](#bundle_executable_dir)
+    *   [bundle_plugins_dir: Expansion of {{bundle_plugins_dir}} in create_bundle.](#bundle_plugins_dir)
+    *   [bundle_resources_dir: Expansion of {{bundle_resources_dir}} in create_bundle.](#bundle_resources_dir)
+    *   [bundle_root_dir: Expansion of {{bundle_root_dir}} in create_bundle.](#bundle_root_dir)
+    *   [cflags: [string list] Flags passed to all C compiler variants.](#cflags)
+    *   [cflags_c: [string list] Flags passed to the C compiler.](#cflags_c)
+    *   [cflags_cc: [string list] Flags passed to the C++ compiler.](#cflags_cc)
+    *   [cflags_objc: [string list] Flags passed to the Objective C compiler.](#cflags_objc)
+    *   [cflags_objcc: [string list] Flags passed to the Objective C++ compiler.](#cflags_objcc)
+    *   [check_includes: [boolean] Controls whether a target's files are checked.](#check_includes)
+    *   [code_signing_args: [string list] Arguments passed to code signing script.](#code_signing_args)
+    *   [code_signing_outputs: [file list] Output files for code signing step.](#code_signing_outputs)
+    *   [code_signing_script: [file name] Script for code signing.](#code_signing_script)
+    *   [code_signing_sources: [file list] Sources for code signing step.](#code_signing_sources)
+    *   [complete_static_lib: [boolean] Links all deps into a static library.](#complete_static_lib)
+    *   [configs: [label list] Configs applying to this target or config.](#configs)
+    *   [data: [file list] Runtime data file dependencies.](#data)
+    *   [data_deps: [label list] Non-linked dependencies.](#data_deps)
+    *   [defines: [string list] C preprocessor defines.](#defines)
+    *   [depfile: [string] File name for input dependencies for actions.](#depfile)
+    *   [deps: [label list] Private linked dependencies.](#deps)
+    *   [friend: [label pattern list] Allow targets to include private headers.](#friend)
+    *   [include_dirs: [directory list] Additional include directories.](#include_dirs)
+    *   [inputs: [file list] Additional compile-time dependencies.](#inputs)
+    *   [ldflags: [string list] Flags passed to the linker.](#ldflags)
+    *   [lib_dirs: [directory list] Additional library directories.](#lib_dirs)
+    *   [libs: [string list] Additional libraries to link.](#libs)
+    *   [output_dir: [directory] Directory to put output file in.](#output_dir)
+    *   [output_extension: [string] Value to use for the output's file extension.](#output_extension)
+    *   [output_name: [string] Name for the output file other than the default.](#output_name)
+    *   [output_prefix_override: [boolean] Don't use prefix for output name.](#output_prefix_override)
+    *   [outputs: [file list] Output files for actions and copy targets.](#outputs)
+    *   [partial_info_plist: [filename] Path plist from asset catalog compiler.](#partial_info_plist)
+    *   [pool: [string] Label of the pool used by the action.](#pool)
+    *   [precompiled_header: [string] Header file to precompile.](#precompiled_header)
+    *   [precompiled_header_type: [string] "gcc" or "msvc".](#precompiled_header_type)
+    *   [precompiled_source: [file name] Source file to precompile.](#precompiled_source)
+    *   [product_type: [string] Product type for Xcode projects.](#product_type)
+    *   [public: [file list] Declare public header files for a target.](#public)
+    *   [public_configs: [label list] Configs applied to dependents.](#public_configs)
+    *   [public_deps: [label list] Declare public dependencies.](#public_deps)
+    *   [response_file_contents: [string list] Contents of .rsp file for actions.](#response_file_contents)
+    *   [script: [file name] Script file for actions.](#script)
+    *   [sources: [file list] Source files for a target.](#sources)
+    *   [testonly: [boolean] Declares a target must only be used for testing.](#testonly)
+    *   [visibility: [label list] A list of labels that can depend on a target.](#visibility)
+    *   [write_runtime_deps: Writes the target's runtime_deps to the given path.](#write_runtime_deps)
+    *   [xcode_extra_attributes: [scope] Extra attributes for Xcode projects.](#xcode_extra_attributes)
+    *   [test_application_name: [string] Test application name for unit or ui test target.](#test_application_name)
+*   [Other help topics](#other)
+    *   [all: Print all the help at once](#all)
+    *   [buildargs: How build arguments work.](#buildargs)
+    *   [dotfile: Info about the toplevel .gn file.](#dotfile)
+    *   [execution: Build graph and execution overview.](#execution)
+    *   [grammar: Language and grammar for GN build files.](#grammar)
+    *   [input_conversion: Processing input from exec_script and read_file.](#input_conversion)
+    *   [label_pattern: Matching more than one label.](#label_pattern)
+    *   [labels: About labels.](#labels)
+    *   [ninja_rules: How Ninja build rules are named.](#ninja_rules)
+    *   [nogncheck: Annotating includes for checking.](#nogncheck)
+    *   [runtime_deps: How runtime dependency computation works.](#runtime_deps)
+    *   [source_expansion: Map sources to outputs for scripts.](#source_expansion)
+    *   [switches: Show available command-line switches.](#switches)
+
+## <a name="commands"></a>Commands
+
+### <a name="analyze"></a>**gn analyze <out_dir> <input_path> <output_path>**
+
+```
+  Analyze which targets are affected by a list of files.
+
+  This command takes three arguments:
+
+  out_dir is the path to the build directory.
+
+  input_path is a path to a file containing a JSON object with three fields:
+
+   - "files": A list of the filenames to check.
+
+   - "test_targets": A list of the labels for targets that are needed to run
+     the tests we wish to run.
+
+   - "additional_compile_targets": A list of the labels for targets that we
+     wish to rebuild, but aren't necessarily needed for testing. The important
+     difference between this field and "test_targets" is that if an item in
+     the additional_compile_targets list refers to a group, then any
+     dependencies of that group will be returned if they are out of date, but
+     the group itself does not need to be. If the dependencies themselves are
+     groups, the same filtering is repeated. This filtering can be used to
+     avoid rebuilding dependencies of a group that are unaffected by the input
+     files. The list may also contain the string "all" to refer to a
+     pseudo-group that contains every root target in the build graph.
+
+     This filtering behavior is also known as "pruning" the list of compile
+     targets.
+
+  output_path is a path indicating where the results of the command are to be
+  written. The results will be a file containing a JSON object with one or more
+  of following fields:
+
+   - "compile_targets": A list of the labels derived from the input
+     compile_targets list that are affected by the input files. Due to the way
+     the filtering works for compile targets as described above, this list may
+     contain targets that do not appear in the input list.
+
+   - "test_targets": A list of the labels from the input test_targets list that
+     are affected by the input files. This list will be a proper subset of the
+     input list.
+
+   - "invalid_targets": A list of any names from the input that do not exist in
+     the build graph. If this list is non-empty, the "error" field will also be
+     set to "Invalid targets".
+
+   - "status": A string containing one of three values:
+
+       - "Found dependency"
+       - "No dependency"
+       - "Found dependency (all) "
+
+     In the first case, the lists returned in compile_targets and test_targets
+     should be passed to ninja to build. In the second case, nothing was
+     affected and no build is necessary. In the third case, GN could not
+     determine the correct answer and returned the input as the output in order
+     to be safe.
+
+   - "error": This will only be present if an error occurred, and will contain
+     a string describing the error. This includes cases where the input file is
+     not in the right format, or contains invalid targets.
+
+  The command returns 1 if it is unable to read the input file or write the
+  output file, or if there is something wrong with the build such that gen
+  would also fail, and 0 otherwise. In particular, it returns 0 even if the
+  "error" key is non-empty and a non-fatal error occurred. In other words, it
+  tries really hard to always write something to the output JSON and convey
+  errors that way rather than via return codes.
+```
+### <a name="args"></a>**gn args <out_dir> [\--list] [\--short] [\--args] [\--overrides-only]**
+
+```
+  See also "gn help buildargs" for a more high-level overview of how
+  build arguments work.
+```
+
+#### **Usage**
+
+```
+  gn args <out_dir>
+      Open the arguments for the given build directory in an editor. If the
+      given build directory doesn't exist, it will be created and an empty args
+      file will be opened in the editor. You would type something like this
+      into that file:
+          enable_doom_melon=false
+          os="android"
+
+      To find your editor on Posix, GN will search the environment variables in
+      order: GN_EDITOR, VISUAL, and EDITOR. On Windows GN will open the command
+      associated with .txt files.
+
+      Note: you can edit the build args manually by editing the file "args.gn"
+      in the build directory and then running "gn gen <out_dir>".
+
+  gn args <out_dir> --list[=<exact_arg>] [--short] [--overrides-only] [--json]
+      Lists all build arguments available in the current configuration, or, if
+      an exact_arg is specified for the list flag, just that one build
+      argument.
+
+      The output will list the declaration location, current value for the
+      build, default value (if different than the current value), and comment
+      preceding the declaration.
+
+      If --short is specified, only the names and current values will be
+      printed.
+
+      If --overrides-only is specified, only the names and current values of
+      arguments that have been overridden (i.e. non-default arguments) will
+      be printed. Overrides come from the <out_dir>/args.gn file and //.gn
+
+      If --json is specified, the output will be emitted in json format.
+      JSON schema for output:
+      [
+        {
+          "name": variable_name,
+          "current": {
+            "value": overridden_value,
+            "file": file_name,
+            "line": line_no
+          },
+          "default": {
+            "value": default_value,
+            "file": file_name,
+            "line": line_no
+          },
+          "comment": comment_string
+        },
+        ...
+      ]
+```
+
+#### **Examples**
+
+```
+  gn args out/Debug
+    Opens an editor with the args for out/Debug.
+
+  gn args out/Debug --list --short
+    Prints all arguments with their default values for the out/Debug
+    build.
+
+  gn args out/Debug --list --short --overrides-only
+    Prints overridden arguments for the out/Debug build.
+
+  gn args out/Debug --list=target_cpu
+    Prints information about the "target_cpu" argument for the "
+   "out/Debug
+    build.
+
+  gn args --list --args="os=\"android\" enable_doom_melon=true"
+    Prints all arguments with the default values for a build with the
+    given arguments set (which may affect the values of other
+    arguments).
+```
+### <a name="check"></a>**gn check <out_dir> [<label_pattern>] [\--force]**
+
+```
+  GN's include header checker validates that the includes for C-like source
+  files match the build dependency graph.
+
+  "gn check" is the same thing as "gn gen" with the "--check" flag except that
+  this command does not write out any build files. It's intended to be an easy
+  way to manually trigger include file checking.
+
+  The <label_pattern> can take exact labels or patterns that match more than
+  one (although not general regular expressions). If specified, only those
+  matching targets will be checked. See "gn help label_pattern" for details.
+```
+
+#### **Command-specific switches**
+
+```
+  --force
+      Ignores specifications of "check_includes = false" and checks all
+      target's files that match the target label.
+```
+
+#### **What gets checked**
+
+```
+  The .gn file may specify a list of targets to be checked. Only these targets
+  will be checked if no label_pattern is specified on the command line.
+  Otherwise, the command-line list is used instead. See "gn help dotfile".
+
+  Targets can opt-out from checking with "check_includes = false" (see
+  "gn help check_includes").
+
+  For targets being checked:
+
+    - GN opens all C-like source files in the targets to be checked and scans
+      the top for includes.
+
+    - Includes with a "nogncheck" annotation are skipped (see
+      "gn help nogncheck").
+
+    - Only includes using "quotes" are checked. <brackets> are assumed to be
+      system includes.
+
+    - Include paths are assumed to be relative to any of the "include_dirs" for
+      the target (including the implicit current dir).
+
+    - GN does not run the preprocessor so will not understand conditional
+      includes.
+
+    - Only includes matching known files in the build are checked: includes
+      matching unknown paths are ignored.
+
+  For an include to be valid:
+
+    - The included file must be in the current target, or there must be a path
+      following only public dependencies to a target with the file in it
+      ("gn path" is a good way to diagnose problems).
+
+    - There can be multiple targets with an included file: only one needs to be
+      valid for the include to be allowed.
+
+    - If there are only "sources" in a target, all are considered to be public
+      and can be included by other targets with a valid public dependency path.
+
+    - If a target lists files as "public", only those files are able to be
+      included by other targets. Anything in the sources will be considered
+      private and will not be includable regardless of dependency paths.
+
+    - Outputs from actions are treated like public sources on that target.
+
+    - A target can include headers from a target that depends on it if the
+      other target is annotated accordingly. See "gn help
+      allow_circular_includes_from".
+```
+
+#### **Advice on fixing problems**
+
+```
+  If you have a third party project that is difficult to fix or doesn't care
+  about include checks it's generally best to exclude that target from checking
+  altogether via "check_includes = false".
+
+  If you have conditional includes, make sure the build conditions and the
+  preprocessor conditions match, and annotate the line with "nogncheck" (see
+  "gn help nogncheck" for an example).
+
+  If two targets are hopelessly intertwined, use the
+  "allow_circular_includes_from" annotation. Ideally each should have identical
+  dependencies so configs inherited from those dependencies are consistent (see
+  "gn help allow_circular_includes_from").
+
+  If you have a standalone header file or files that need to be shared between
+  a few targets, you can consider making a source_set listing only those
+  headers as public sources. With only header files, the source set will be a
+  no-op from a build perspective, but will give a central place to refer to
+  those headers. That source set's files will still need to pass "gn check" in
+  isolation.
+
+  In rare cases it makes sense to list a header in more than one target if it
+  could be considered conceptually a member of both.
+```
+
+#### **Examples**
+
+```
+  gn check out/Debug
+      Check everything.
+
+  gn check out/Default //foo:bar
+      Check only the files in the //foo:bar target.
+
+  gn check out/Default "//foo/*
+      Check only the files in targets in the //foo directory tree.
+```
+### <a name="clean"></a>**gn clean <out_dir>**
+
+```
+  Deletes the contents of the output directory except for args.gn and
+  creates a Ninja build environment sufficient to regenerate the build.
+```
+### <a name="desc"></a>**gn desc <out_dir> <label or pattern> [<what to show>] [\--blame] "**
+#### **[\--format=json]**
+
+```
+  Displays information about a given target or config. The build build
+  parameters will be taken for the build in the given <out_dir>.
+
+  The <label or pattern> can be a target label, a config label, or a label
+  pattern (see "gn help label_pattern"). A label pattern will only match
+  targets.
+```
+
+#### **Possibilities for <what to show>**
+
+```
+  (If unspecified an overall summary will be displayed.)
+
+  all_dependent_configs
+  allow_circular_includes_from
+  arflags [--blame]
+  args
+  cflags [--blame]
+  cflags_cc [--blame]
+  cflags_cxx [--blame]
+  check_includes
+  configs [--tree] (see below)
+  defines [--blame]
+  depfile
+  deps [--all] [--tree] (see below)
+  include_dirs [--blame]
+  inputs
+  ldflags [--blame]
+  lib_dirs
+  libs
+  outputs
+  public_configs
+  public
+  script
+  sources
+  testonly
+  visibility
+
+  runtime_deps
+      Compute all runtime deps for the given target. This is a computed list
+      and does not correspond to any GN variable, unlike most other values
+      here.
+
+      The output is a list of file names relative to the build directory. See
+      "gn help runtime_deps" for how this is computed. This also works with
+      "--blame" to see the source of the dependency.
+```
+
+#### **Shared flags**
+```
+  --all-toolchains
+      Normally only inputs in the default toolchain will be included.
+      This switch will turn on matching all toolchains.
+
+      For example, a file is in a target might be compiled twice:
+      once in the default toolchain and once in a secondary one. Without
+      this flag, only the default toolchain one will be matched by
+      wildcards. With this flag, both will be matched.
+
+  --format=json
+      Format the output as JSON instead of text.
+```
+
+#### **Target flags**
+
+```
+  --blame
+      Used with any value specified on a config, this will name the config that
+      cause that target to get the flag. This doesn't currently work for libs
+      and lib_dirs because those are inherited and are more complicated to
+      figure out the blame (patches welcome).
+```
+
+#### **Configs**
+
+```
+  The "configs" section will list all configs that apply. For targets this will
+  include configs specified in the "configs" variable of the target, and also
+  configs pushed onto this target via public or "all dependent" configs.
+
+  Configs can have child configs. Specifying --tree will show the hierarchy.
+```
+
+#### **Printing outputs**
+
+```
+  The "outputs" section will list all outputs that apply, including the outputs
+  computed from the tool definition (eg for "executable", "static_library", ...
+  targets).
+```
+
+#### **Printing deps**
+
+```
+  Deps will include all public, private, and data deps (TODO this could be
+  clarified and enhanced) sorted in order applying. The following may be used:
+
+  --all
+      Collects all recursive dependencies and prints a sorted flat list. Also
+      usable with --tree (see below).
+  --as=(buildfile|label|output)
+      How to print targets.
+
+      buildfile
+          Prints the build files where the given target was declared as
+          file names.
+      label  (default)
+          Prints the label of the target.
+      output
+          Prints the first output file for the target relative to the
+          root build directory.
+
+  --testonly=(true|false)
+      Restrict outputs to targets with the testonly flag set
+      accordingly. When unspecified, the target's testonly flags are
+      ignored.
+
+  --tree
+      Print a dependency tree. By default, duplicates will be elided with "..."
+      but when --all and -tree are used together, no eliding will be performed.
+
+      The "deps", "public_deps", and "data_deps" will all be included in the
+      tree.
+
+      Tree output can not be used with the filtering or output flags: --as,
+      --type, --testonly.
+  --type=(action|copy|executable|group|loadable_module|shared_library|
+          source_set|static_library)
+      Restrict outputs to targets matching the given type. If
+      unspecified, no filtering will be performed.
+```
+
+#### **Note**
+
+```
+  This command will show the full name of directories and source files, but
+  when directories and source paths are written to the build file, they will be
+  adjusted to be relative to the build directory. So the values for paths
+  displayed by this command won't match (but should mean the same thing).
+```
+
+#### **Examples**
+
+```
+  gn desc out/Debug //base:base
+      Summarizes the given target.
+
+  gn desc out/Foo :base_unittests deps --tree
+      Shows a dependency tree of the "base_unittests" project in
+      the current directory.
+
+  gn desc out/Debug //base defines --blame
+      Shows defines set for the //base:base target, annotated by where
+      each one was set from.
+```
+### <a name="format"></a>**gn format [\--dump-tree] (\--stdin | <build_file>)**
+
+```
+  Formats .gn file to a standard format.
+
+  The contents of some lists ('sources', 'deps', etc.) will be sorted to a
+  canonical order. To suppress this, you can add a comment of the form "#
+  NOSORT" immediately preceding the assignment. e.g.
+
+  # NOSORT
+  sources = [
+    "z.cc",
+    "a.cc",
+  ]
+```
+
+#### **Arguments**
+
+```
+  --dry-run
+      Does not change or output anything, but sets the process exit code based
+      on whether output would be different than what's on disk. This is useful
+      for presubmit/lint-type checks.
+      - Exit code 0: successful format, matches on disk.
+      - Exit code 1: general failure (parse error, etc.)
+      - Exit code 2: successful format, but differs from on disk.
+
+  --dump-tree
+      For debugging, dumps the parse tree to stdout and does not update the
+      file or print formatted output.
+
+  --stdin
+      Read input from stdin and write to stdout rather than update a file
+      in-place.
+```
+
+#### **Examples**
+```
+  gn format //some/BUILD.gn
+  gn format some\\BUILD.gn
+  gn format /abspath/some/BUILD.gn
+  gn format --stdin
+```
+### <a name="gen"></a>**gn gen [\--check] [<ide options>] <out_dir>**
+
+```
+  Generates ninja files from the current tree and puts them in the given output
+  directory.
+
+  The output directory can be a source-repo-absolute path name such as:
+      //out/foo
+  Or it can be a directory relative to the current directory such as:
+      out/foo
+
+  "gn gen --check" is the same as running "gn check". See "gn help check"
+  for documentation on that mode.
+
+  See "gn help switches" for the common command-line switches.
+```
+
+#### **IDE options**
+
+```
+  GN optionally generates files for IDE. Possibilities for <ide options>
+
+  --ide=<ide_name>
+      Generate files for an IDE. Currently supported values:
+      "eclipse" - Eclipse CDT settings file.
+      "vs" - Visual Studio project/solution files.
+             (default Visual Studio version: 2017)
+      "vs2013" - Visual Studio 2013 project/solution files.
+      "vs2015" - Visual Studio 2015 project/solution files.
+      "vs2017" - Visual Studio 2017 project/solution files.
+      "xcode" - Xcode workspace/solution files.
+      "qtcreator" - QtCreator project files.
+      "json" - JSON file containing target information
+
+  --filters=<path_prefixes>
+      Semicolon-separated list of label patterns used to limit the set of
+      generated projects (see "gn help label_pattern"). Only matching targets
+      and their dependencies will be included in the solution. Only used for
+      Visual Studio, Xcode and JSON.
+```
+
+#### **Visual Studio Flags**
+
+```
+  --sln=<file_name>
+      Override default sln file name ("all"). Solution file is written to the
+      root build directory.
+
+  --no-deps
+      Don't include targets dependencies to the solution. Changes the way how
+      --filters option works. Only directly matching targets are included.
+
+  --winsdk=<sdk_version>
+      Use the specified Windows 10 SDK version to generate project files.
+      As an example, "10.0.15063.0" can be specified to use Creators Update SDK
+      instead of the default one.
+
+  --ninja-extra-args=<string>
+      This string is passed without any quoting to the ninja invocation
+      command-line. Can be used to configure ninja flags, like "-j".
+```
+
+#### **Xcode Flags**
+
+```
+  --workspace=<file_name>
+      Override defaut workspace file name ("all"). The workspace file is
+      written to the root build directory.
+
+  --ninja-extra-args=<string>
+      This string is passed without any quoting to the ninja invocation
+      command-line. Can be used to configure ninja flags, like "-j".
+
+  --root-target=<target_name>
+      Name of the target corresponding to "All" target in Xcode. If unset,
+      "All" invokes ninja without any target and builds everything.
+```
+
+#### **QtCreator Flags**
+
+```
+  --root-target=<target_name>
+      Name of the root target for which the QtCreator project will be generated
+      to contain files of it and its dependencies. If unset, the whole build
+      graph will be emitted.
+```
+
+#### **Eclipse IDE Support**
+
+```
+  GN DOES NOT generate Eclipse CDT projects. Instead, it generates a settings
+  file which can be imported into an Eclipse CDT project. The XML file contains
+  a list of include paths and defines. Because GN does not generate a full
+  .cproject definition, it is not possible to properly define includes/defines
+  for each file individually. Instead, one set of includes/defines is generated
+  for the entire project. This works fairly well but may still result in a few
+  indexer issues here and there.
+```
+
+#### **Generic JSON Output**
+
+```
+  Dumps target information to a JSON file and optionally invokes a
+  python script on the generated file. See the comments at the beginning
+  of json_project_writer.cc and desc_builder.cc for an overview of the JSON
+  file format.
+
+  --json-file-name=<json_file_name>
+      Overrides default file name (project.json) of generated JSON file.
+
+  --json-ide-script=<path_to_python_script>
+      Executes python script after the JSON file is generated. Path can be
+      project absolute (//), system absolute (/) or relative, in which case the
+      output directory will be base. Path to generated JSON file will be first
+      argument when invoking script.
+
+  --json-ide-script-args=<argument>
+      Optional second argument that will passed to executed script.
+```
+### <a name="help"></a>**gn help <anything>**
+
+```
+  Yo dawg, I heard you like help on your help so I put help on the help in the
+  help.
+
+  You can also use "all" as the parameter to get all help at once.
+```
+
+#### **Switches**
+
+```
+  --markdown
+      Format output in markdown syntax.
+```
+
+#### **Example**
+
+```
+  gn help --markdown all
+      Dump all help to stdout in markdown format.
+```
+### <a name="ls"></a>**gn ls <out_dir> [<label_pattern>] [\--all-toolchains] [\--as=...]**
+```
+      [--type=...] [--testonly=...]
+
+  Lists all targets matching the given pattern for the given build directory.
+  By default, only targets in the default toolchain will be matched unless a
+  toolchain is explicitly supplied.
+
+  If the label pattern is unspecified, list all targets. The label pattern is
+  not a general regular expression (see "gn help label_pattern"). If you need
+  more complex expressions, pipe the result through grep.
+```
+
+#### **Options**
+
+```
+  --as=(buildfile|label|output)
+      How to print targets.
+
+      buildfile
+          Prints the build files where the given target was declared as
+          file names.
+      label  (default)
+          Prints the label of the target.
+      output
+          Prints the first output file for the target relative to the
+          root build directory.
+
+  --all-toolchains
+      Normally only inputs in the default toolchain will be included.
+      This switch will turn on matching all toolchains.
+
+      For example, a file is in a target might be compiled twice:
+      once in the default toolchain and once in a secondary one. Without
+      this flag, only the default toolchain one will be matched by
+      wildcards. With this flag, both will be matched.
+
+  --testonly=(true|false)
+      Restrict outputs to targets with the testonly flag set
+      accordingly. When unspecified, the target's testonly flags are
+      ignored.
+
+  --type=(action|copy|executable|group|loadable_module|shared_library|
+          source_set|static_library)
+      Restrict outputs to targets matching the given type. If
+      unspecified, no filtering will be performed.
+```
+
+#### **Examples**
+
+```
+  gn ls out/Debug
+      Lists all targets in the default toolchain.
+
+  gn ls out/Debug "//base/*"
+      Lists all targets in the directory base and all subdirectories.
+
+  gn ls out/Debug "//base:*"
+      Lists all targets defined in //base/BUILD.gn.
+
+  gn ls out/Debug //base --as=output
+      Lists the build output file for //base:base
+
+  gn ls out/Debug --type=executable
+      Lists all executables produced by the build.
+
+  gn ls out/Debug "//base/*" --as=output | xargs ninja -C out/Debug
+      Builds all targets in //base and all subdirectories.
+
+  gn ls out/Debug //base --all-toolchains
+      Lists all variants of the target //base:base (it may be referenced
+      in multiple toolchains).
+```
+### <a name="path"></a>**gn path <out_dir> <target_one> <target_two>**
+
+```
+  Finds paths of dependencies between two targets. Each unique path will be
+  printed in one group, and groups will be separate by newlines. The two
+  targets can appear in either order (paths will be found going in either
+  direction).
+
+  By default, a single path will be printed. If there is a path with only
+  public dependencies, the shortest public path will be printed. Otherwise, the
+  shortest path using either public or private dependencies will be printed. If
+  --with-data is specified, data deps will also be considered. If there are
+  multiple shortest paths, an arbitrary one will be selected.
+```
+
+#### **Interesting paths**
+
+```
+  In a large project, there can be 100's of millions of unique paths between a
+  very high level and a common low-level target. To make the output more useful
+  (and terminate in a reasonable time), GN will not revisit sub-paths
+  previously known to lead to the target.
+```
+
+#### **Options**
+
+```
+  --all
+     Prints all "interesting" paths found rather than just the first one.
+     Public paths will be printed first in order of increasing length, followed
+     by non-public paths in order of increasing length.
+
+  --public
+     Considers only public paths. Can't be used with --with-data.
+
+  --with-data
+     Additionally follows data deps. Without this flag, only public and private
+     linked deps will be followed. Can't be used with --public.
+```
+
+#### **Example**
+
+```
+  gn path out/Default //base //tools/gn
+```
+### <a name="refs"></a>**gn refs <out_dir> (<label_pattern>|<label>|<file>|@<response_file>)***
+```
+        [--all] [--all-toolchains] [--as=...] [--testonly=...] [--type=...]
+
+  Finds reverse dependencies (which targets reference something). The input is
+  a list containing:
+
+   - Target label: The result will be which targets depend on it.
+
+   - Config label: The result will be which targets list the given config in
+     its "configs" or "public_configs" list.
+
+   - Label pattern: The result will be which targets depend on any target
+     matching the given pattern. Patterns will not match configs. These are not
+     general regular expressions, see "gn help label_pattern" for details.
+
+   - File name: The result will be which targets list the given file in its
+     "inputs", "sources", "public", "data", or "outputs". Any input that does
+     not contain wildcards and does not match a target or a config will be
+     treated as a file.
+
+   - Response file: If the input starts with an "@", it will be interpreted as
+     a path to a file containing a list of labels or file names, one per line.
+     This allows us to handle long lists of inputs without worrying about
+     command line limits.
+```
+
+#### **Options**
+
+```
+  --all
+      When used without --tree, will recurse and display all unique
+      dependencies of the given targets. For example, if the input is a target,
+      this will output all targets that depend directly or indirectly on the
+      input. If the input is a file, this will output all targets that depend
+      directly or indirectly on that file.
+
+      When used with --tree, turns off eliding to show a complete tree.
+  --all-toolchains
+      Normally only inputs in the default toolchain will be included.
+      This switch will turn on matching all toolchains.
+
+      For example, a file is in a target might be compiled twice:
+      once in the default toolchain and once in a secondary one. Without
+      this flag, only the default toolchain one will be matched by
+      wildcards. With this flag, both will be matched.
+
+  --as=(buildfile|label|output)
+      How to print targets.
+
+      buildfile
+          Prints the build files where the given target was declared as
+          file names.
+      label  (default)
+          Prints the label of the target.
+      output
+          Prints the first output file for the target relative to the
+          root build directory.
+
+  -q
+     Quiet. If nothing matches, don't print any output. Without this option, if
+     there are no matches there will be an informational message printed which
+     might interfere with scripts processing the output.
+  --testonly=(true|false)
+      Restrict outputs to targets with the testonly flag set
+      accordingly. When unspecified, the target's testonly flags are
+      ignored.
+
+  --tree
+      Outputs a reverse dependency tree from the given target. Duplicates will
+      be elided. Combine with --all to see a full dependency tree.
+
+      Tree output can not be used with the filtering or output flags: --as,
+      --type, --testonly.
+  --type=(action|copy|executable|group|loadable_module|shared_library|
+          source_set|static_library)
+      Restrict outputs to targets matching the given type. If
+      unspecified, no filtering will be performed.
+```
+
+#### **Examples (target input)**
+
+```
+  gn refs out/Debug //tools/gn:gn
+      Find all targets depending on the given exact target name.
+
+  gn refs out/Debug //base:i18n --as=buildfiles | xargs gvim
+      Edit all .gn files containing references to //base:i18n
+
+  gn refs out/Debug //base --all
+      List all targets depending directly or indirectly on //base:base.
+
+  gn refs out/Debug "//base/*"
+      List all targets depending directly on any target in //base or
+      its subdirectories.
+
+  gn refs out/Debug "//base:*"
+      List all targets depending directly on any target in
+      //base/BUILD.gn.
+
+  gn refs out/Debug //base --tree
+      Print a reverse dependency tree of //base:base
+```
+
+#### **Examples (file input)**
+
+```
+  gn refs out/Debug //base/macros.h
+      Print target(s) listing //base/macros.h as a source.
+
+  gn refs out/Debug //base/macros.h --tree
+      Display a reverse dependency tree to get to the given file. This
+      will show how dependencies will reference that file.
+
+  gn refs out/Debug //base/macros.h //base/at_exit.h --all
+      Display all unique targets with some dependency path to a target
+      containing either of the given files as a source.
+
+  gn refs out/Debug //base/macros.h --testonly=true --type=executable
+          --all --as=output
+      Display the executable file names of all test executables
+      potentially affected by a change to the given file.
+```
+## <a name="targets"></a>Target declarations
+
+### <a name="action"></a>**action**: Declare a target that runs a script a single time.
+
+```
+  This target type allows you to run a script a single time to produce one or
+  more output files. If you want to run a script once for each of a set of
+  input files, see "gn help action_foreach".
+```
+
+#### **Inputs**
+
+```
+  In an action the "sources" and "inputs" are treated the same: they're both
+  input dependencies on script execution with no special handling. If you want
+  to pass the sources to your script, you must do so explicitly by including
+  them in the "args". Note also that this means there is no special handling of
+  paths since GN doesn't know which of the args are paths and not. You will
+  want to use rebase_path() to convert paths to be relative to the
+  root_build_dir.
+
+  You can dynamically write input dependencies (for incremental rebuilds if an
+  input file changes) by writing a depfile when the script is run (see "gn help
+  depfile"). This is more flexible than "inputs".
+
+  If the command line length is very long, you can use response files to pass
+  args to your script. See "gn help response_file_contents".
+
+  It is recommended you put inputs to your script in the "sources" variable,
+  and stuff like other Python files required to run your script in the "inputs"
+  variable.
+  The "deps" and "public_deps" for an action will always be
+  completed before any part of the action is run so it can depend on
+  the output of previous steps. The "data_deps" will be built if the
+  action is built, but may not have completed before all steps of the
+  action are started. This can give additional parallelism in the build
+  for runtime-only dependencies.
+```
+
+#### **Outputs**
+
+```
+  You should specify files created by your script by specifying them in the
+  "outputs".
+  The script will be executed with the given arguments with the current
+  directory being that of the root build directory. If you pass files
+  to your script, see "gn help rebase_path" for how to convert
+  file names to be relative to the build directory (file names in the
+  sources, outputs, and inputs will be all treated as relative to the
+  current build file and converted as needed automatically).
+```
+
+#### **File name handling**
+```
+  All output files must be inside the output directory of the build.
+  You would generally use |$target_out_dir| or |$target_gen_dir| to
+  reference the output or generated intermediate file directories,
+  respectively.
+```
+
+#### **Variables**
+
+```
+  args, data, data_deps, depfile, deps, inputs, outputs*, pool,
+  response_file_contents, script*, sources
+  * = required
+```
+
+#### **Example**
+
+```
+  action("run_this_guy_once") {
+    script = "doprocessing.py"
+    sources = [ "my_configuration.txt" ]
+    outputs = [ "$target_gen_dir/insightful_output.txt" ]
+
+    # Our script imports this Python file so we want to rebuild if it changes.
+    inputs = [ "helper_library.py" ]
+
+    # Note that we have to manually pass the sources to our script if the
+    # script needs them as inputs.
+    args = [ "--out", rebase_path(target_gen_dir, root_build_dir) ] +
+           rebase_path(sources, root_build_dir)
+  }
+```
+### <a name="action_foreach"></a>**action_foreach**: Declare a target that runs a script over a set of files.
+
+```
+  This target type allows you to run a script once-per-file over a set of
+  sources. If you want to run a script once that takes many files as input, see
+  "gn help action".
+```
+
+#### **Inputs**
+
+```
+  The script will be run once per file in the "sources" variable. The "outputs"
+  variable should specify one or more files with a source expansion pattern in
+  it (see "gn help source_expansion"). The output file(s) for each script
+  invocation should be unique. Normally you use "{{source_name_part}}" in each
+  output file.
+
+  If your script takes additional data as input, such as a shared configuration
+  file or a Python module it uses, those files should be listed in the "inputs"
+  variable. These files are treated as dependencies of each script invocation.
+
+  If the command line length is very long, you can use response files to pass
+  args to your script. See "gn help response_file_contents".
+
+  You can dynamically write input dependencies (for incremental rebuilds if an
+  input file changes) by writing a depfile when the script is run (see "gn help
+  depfile"). This is more flexible than "inputs".
+  The "deps" and "public_deps" for an action will always be
+  completed before any part of the action is run so it can depend on
+  the output of previous steps. The "data_deps" will be built if the
+  action is built, but may not have completed before all steps of the
+  action are started. This can give additional parallelism in the build
+  for runtime-only dependencies.
+```
+
+#### **Outputs**
+```
+  The script will be executed with the given arguments with the current
+  directory being that of the root build directory. If you pass files
+  to your script, see "gn help rebase_path" for how to convert
+  file names to be relative to the build directory (file names in the
+  sources, outputs, and inputs will be all treated as relative to the
+  current build file and converted as needed automatically).
+```
+
+#### **File name handling**
+```
+  All output files must be inside the output directory of the build.
+  You would generally use |$target_out_dir| or |$target_gen_dir| to
+  reference the output or generated intermediate file directories,
+  respectively.
+```
+
+#### **Variables**
+
+```
+  args, data, data_deps, depfile, deps, inputs, outputs*, pool,
+  response_file_contents, script*, sources*
+  * = required
+```
+
+#### **Example**
+
+```
+  # Runs the script over each IDL file. The IDL script will generate both a .cc
+  # and a .h file for each input.
+  action_foreach("my_idl") {
+    script = "idl_processor.py"
+    sources = [ "foo.idl", "bar.idl" ]
+
+    # Our script reads this file each time, so we need to list is as a
+    # dependency so we can rebuild if it changes.
+    inputs = [ "my_configuration.txt" ]
+
+    # Transformation from source file name to output file names.
+    outputs = [ "$target_gen_dir/{{source_name_part}}.h",
+                "$target_gen_dir/{{source_name_part}}.cc" ]
+
+    # Note that since "args" is opaque to GN, if you specify paths here, you
+    # will need to convert it to be relative to the build directory using
+    # rebase_path().
+    args = [
+      "{{source}}",
+      "-o",
+      rebase_path(relative_target_gen_dir, root_build_dir) +
+        "/{{source_name_part}}.h" ]
+  }
+```
+### <a name="bundle_data"></a>**bundle_data**: [iOS/macOS] Declare a target without output.
+
+```
+  This target type allows to declare data that is required at runtime. It is
+  used to inform "create_bundle" targets of the files to copy into generated
+  bundle, see "gn help create_bundle" for help.
+
+  The target must define a list of files as "sources" and a single "outputs".
+  If there are multiple files, source expansions must be used to express the
+  output. The output must reference a file inside of {{bundle_root_dir}}.
+
+  This target can be used on all platforms though it is designed only to
+  generate iOS/macOS bundle. In cross-platform projects, it is advised to put it
+  behind iOS/macOS conditionals.
+
+  See "gn help create_bundle" for more information.
+```
+
+#### **Variables**
+
+```
+  sources*, outputs*, deps, data_deps, public_deps, visibility
+  * = required
+```
+
+#### **Examples**
+
+```
+  bundle_data("icudata") {
+    sources = [ "sources/data/in/icudtl.dat" ]
+    outputs = [ "{{bundle_resources_dir}}/{{source_file_part}}" ]
+  }
+
+  bundle_data("base_unittests_bundle_data]") {
+    sources = [ "test/data" ]
+    outputs = [
+      "{{bundle_resources_dir}}/{{source_root_relative_dir}}/" +
+          "{{source_file_part}}"
+    ]
+  }
+
+  bundle_data("material_typography_bundle_data") {
+    sources = [
+      "src/MaterialTypography.bundle/Roboto-Bold.ttf",
+      "src/MaterialTypography.bundle/Roboto-Italic.ttf",
+      "src/MaterialTypography.bundle/Roboto-Regular.ttf",
+      "src/MaterialTypography.bundle/Roboto-Thin.ttf",
+    ]
+    outputs = [
+      "{{bundle_resources_dir}}/MaterialTypography.bundle/"
+          "{{source_file_part}}"
+    ]
+  }
+```
+### <a name="copy"></a>**copy**: Declare a target that copies files.
+
+#### **File name handling**
+
+```
+  All output files must be inside the output directory of the build. You would
+  generally use |$target_out_dir| or |$target_gen_dir| to reference the output
+  or generated intermediate file directories, respectively.
+
+  Both "sources" and "outputs" must be specified. Sources can include as many
+  files as you want, but there can only be one item in the outputs list (plural
+  is used for the name for consistency with other target types).
+
+  If there is more than one source file, your output name should specify a
+  mapping from each source file to an output file name using source expansion
+  (see "gn help source_expansion"). The placeholders will look like
+  "{{source_name_part}}", for example.
+```
+
+#### **Examples**
+
+```
+  # Write a rule that copies a checked-in DLL to the output directory.
+  copy("mydll") {
+    sources = [ "mydll.dll" ]
+    outputs = [ "$target_out_dir/mydll.dll" ]
+  }
+
+  # Write a rule to copy several files to the target generated files directory.
+  copy("myfiles") {
+    sources = [ "data1.dat", "data2.dat", "data3.dat" ]
+
+    # Use source expansion to generate output files with the corresponding file
+    # names in the gen dir. This will just copy each file.
+    outputs = [ "$target_gen_dir/{{source_file_part}}" ]
+  }
+```
+### <a name="create_bundle"></a>**create_bundle**: [ios/macOS] Build an iOS or macOS bundle.
+
+```
+  This target generates an iOS or macOS bundle (which is a directory with a
+  well-know structure). This target does not define any sources, instead they
+  are computed from all "bundle_data" target this one depends on transitively
+  (the recursion stops at "create_bundle" targets).
+
+  The "bundle_*_dir" properties must be defined. They will be used for the
+  expansion of {{bundle_*_dir}} rules in "bundle_data" outputs.
+
+  This target can be used on all platforms though it is designed only to
+  generate iOS or macOS bundle. In cross-platform projects, it is advised to put
+  it behind iOS/macOS conditionals.
+
+  If a create_bundle is specified as a data_deps for another target, the bundle
+  is considered a leaf, and its public and private dependencies will not
+  contribute to any data or data_deps. Required runtime dependencies should be
+  placed in the bundle. A create_bundle can declare its own explicit data and
+  data_deps, however.
+```
+
+#### **Code signing**
+
+```
+  Some bundle needs to be code signed as part of the build (on iOS all
+  application needs to be code signed to run on a device). The code signature
+  can be configured via the code_signing_script variable.
+
+  If set, code_signing_script is the path of a script that invoked after all
+  files have been moved into the bundle. The script must not change any file in
+  the bundle, but may add new files.
+
+  If code_signing_script is defined, then code_signing_outputs must also be
+  defined and non-empty to inform when the script needs to be re-run. The
+  code_signing_args will be passed as is to the script (so path have to be
+  rebased) and additional inputs may be listed with the variable
+  code_signing_sources.
+```
+
+#### **Variables**
+
+```
+  bundle_root_dir*, bundle_contents_dir*, bundle_resources_dir*,
+  bundle_executable_dir*, bundle_plugins_dir*, bundle_deps_filter, deps,
+  data_deps, public_deps, visibility, product_type, code_signing_args,
+  code_signing_script, code_signing_sources, code_signing_outputs,
+  xcode_extra_attributes, xcode_test_application_name, partial_info_plist
+  * = required
+```
+
+#### **Example**
+
+```
+  # Defines a template to create an application. On most platform, this is just
+  # an alias for an "executable" target, but on iOS/macOS, it builds an
+  # application bundle.
+  template("app") {
+    if (!is_ios && !is_mac) {
+      executable(target_name) {
+        forward_variables_from(invoker, "*")
+      }
+    } else {
+      app_name = target_name
+      gen_path = target_gen_dir
+
+      action("${app_name}_generate_info_plist") {
+        script = [ "//build/ios/ios_gen_plist.py" ]
+        sources = [ "templates/Info.plist" ]
+        outputs = [ "$gen_path/Info.plist" ]
+        args = rebase_path(sources, root_build_dir) +
+               rebase_path(outputs, root_build_dir)
+      }
+
+      bundle_data("${app_name}_bundle_info_plist") {
+        deps = [ ":${app_name}_generate_info_plist" ]
+        sources = [ "$gen_path/Info.plist" ]
+        outputs = [ "{{bundle_contents_dir}}/Info.plist" ]
+      }
+
+      executable("${app_name}_generate_executable") {
+        forward_variables_from(invoker, "*", [
+                                               "output_name",
+                                               "visibility",
+                                             ])
+        output_name =
+            rebase_path("$gen_path/$app_name", root_build_dir)
+      }
+
+      code_signing =
+          defined(invoker.code_signing) && invoker.code_signing
+
+      if (is_ios && !code_signing) {
+        bundle_data("${app_name}_bundle_executable") {
+          deps = [ ":${app_name}_generate_executable" ]
+          sources = [ "$gen_path/$app_name" ]
+          outputs = [ "{{bundle_executable_dir}}/$app_name" ]
+        }
+      }
+
+      create_bundle("${app_name}.app") {
+        product_type = "com.apple.product-type.application"
+
+        if (is_ios) {
+          bundle_root_dir = "${root_build_dir}/$target_name"
+          bundle_contents_dir = bundle_root_dir
+          bundle_resources_dir = bundle_contents_dir
+          bundle_executable_dir = bundle_contents_dir
+          bundle_plugins_dir = "${bundle_contents_dir}/Plugins"
+
+          extra_attributes = {
+            ONLY_ACTIVE_ARCH = "YES"
+            DEBUG_INFORMATION_FORMAT = "dwarf"
+          }
+        } else {
+          bundle_root_dir = "${root_build_dir}/target_name"
+          bundle_contents_dir  = "${bundle_root_dir}/Contents"
+          bundle_resources_dir = "${bundle_contents_dir}/Resources"
+          bundle_executable_dir = "${bundle_contents_dir}/MacOS"
+          bundle_plugins_dir = "${bundle_contents_dir}/Plugins"
+        }
+        deps = [ ":${app_name}_bundle_info_plist" ]
+        if (is_ios && code_signing) {
+          deps += [ ":${app_name}_generate_executable" ]
+          code_signing_script = "//build/config/ios/codesign.py"
+          code_signing_sources = [
+            invoker.entitlements_path,
+            "$target_gen_dir/$app_name",
+          ]
+          code_signing_outputs = [
+            "$bundle_root_dir/$app_name",
+            "$bundle_root_dir/_CodeSignature/CodeResources",
+            "$bundle_root_dir/embedded.mobileprovision",
+            "$target_gen_dir/$app_name.xcent",
+          ]
+          code_signing_args = [
+            "-i=" + ios_code_signing_identity,
+            "-b=" + rebase_path(
+                "$target_gen_dir/$app_name", root_build_dir),
+            "-e=" + rebase_path(
+                invoker.entitlements_path, root_build_dir),
+            "-e=" + rebase_path(
+                "$target_gen_dir/$app_name.xcent", root_build_dir),
+            rebase_path(bundle_root_dir, root_build_dir),
+          ]
+        } else {
+          deps += [ ":${app_name}_bundle_executable" ]
+        }
+      }
+    }
+  }
+```
+### <a name="executable"></a>**executable**: Declare an executable target.
+
+#### **Variables**
+
+```
+  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
+         asmflags, defines, include_dirs, inputs, ldflags, lib_dirs,
+         libs, precompiled_header, precompiled_source
+  Deps: data_deps, deps, public_deps
+  Dependent configs: all_dependent_configs, public_configs
+  General: check_includes, configs, data, friend, inputs, output_name,
+           output_extension, public, sources, testonly, visibility
+```
+### <a name="group"></a>**group**: Declare a named group of targets.
+
+```
+  This target type allows you to create meta-targets that just collect a set of
+  dependencies into one named target. Groups can additionally specify configs
+  that apply to their dependents.
+```
+
+#### **Variables**
+
+```
+  Deps: data_deps, deps, public_deps
+  Dependent configs: all_dependent_configs, public_configs
+```
+
+#### **Example**
+
+```
+  group("all") {
+    deps = [
+      "//project:runner",
+      "//project:unit_tests",
+    ]
+  }
+```
+### <a name="loadable_module"></a>**loadable_module**: Declare a loadable module target.
+
+```
+  This target type allows you to create an object file that is (and can only
+  be) loaded and unloaded at runtime.
+
+  A loadable module will be specified on the linker line for targets listing
+  the loadable module in its "deps". If you don't want this (if you don't need
+  to dynamically load the library at runtime), then you should use a
+  "shared_library" target type instead.
+```
+
+#### **Variables**
+
+```
+  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
+         asmflags, defines, include_dirs, inputs, ldflags, lib_dirs,
+         libs, precompiled_header, precompiled_source
+  Deps: data_deps, deps, public_deps
+  Dependent configs: all_dependent_configs, public_configs
+  General: check_includes, configs, data, friend, inputs, output_name,
+           output_extension, public, sources, testonly, visibility
+```
+### <a name="shared_library"></a>**shared_library**: Declare a shared library target.
+
+```
+  A shared library will be specified on the linker line for targets listing the
+  shared library in its "deps". If you don't want this (say you dynamically
+  load the library at runtime), then you should depend on the shared library
+  via "data_deps" or, on Darwin platforms, use a "loadable_module" target type
+  instead.
+```
+
+#### **Variables**
+
+```
+  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
+         asmflags, defines, include_dirs, inputs, ldflags, lib_dirs,
+         libs, precompiled_header, precompiled_source
+  Deps: data_deps, deps, public_deps
+  Dependent configs: all_dependent_configs, public_configs
+  General: check_includes, configs, data, friend, inputs, output_name,
+           output_extension, public, sources, testonly, visibility
+```
+### <a name="source_set"></a>**source_set**: Declare a source set target.
+
+```
+  A source set is a collection of sources that get compiled, but are not linked
+  to produce any kind of library. Instead, the resulting object files are
+  implicitly added to the linker line of all targets that depend on the source
+  set.
+
+  In most cases, a source set will behave like a static library, except no
+  actual library file will be produced. This will make the build go a little
+  faster by skipping creation of a large static library, while maintaining the
+  organizational benefits of focused build targets.
+
+  The main difference between a source set and a static library is around
+  handling of exported symbols. Most linkers assume declaring a function
+  exported means exported from the static library. The linker can then do dead
+  code elimination to delete code not reachable from exported functions.
+
+  A source set will not do this code elimination since there is no link step.
+  This allows you to link many sources sets into a shared library and have the
+  "exported symbol" notation indicate "export from the final shared library and
+  not from the intermediate targets." There is no way to express this concept
+  when linking multiple static libraries into a shared library.
+```
+
+#### **Variables**
+
+```
+  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
+         asmflags, defines, include_dirs, inputs, ldflags, lib_dirs,
+         libs, precompiled_header, precompiled_source
+  Deps: data_deps, deps, public_deps
+  Dependent configs: all_dependent_configs, public_configs
+  General: check_includes, configs, data, friend, inputs, output_name,
+           output_extension, public, sources, testonly, visibility
+```
+### <a name="static_library"></a>**static_library**: Declare a static library target.
+
+```
+  Make a ".a" / ".lib" file.
+
+  If you only need the static library for intermediate results in the build,
+  you should consider a source_set instead since it will skip the (potentially
+  slow) step of creating the intermediate library file.
+```
+
+#### **Variables**
+
+```
+  complete_static_lib
+  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
+         asmflags, defines, include_dirs, inputs, ldflags, lib_dirs,
+         libs, precompiled_header, precompiled_source
+  Deps: data_deps, deps, public_deps
+  Dependent configs: all_dependent_configs, public_configs
+  General: check_includes, configs, data, friend, inputs, output_name,
+           output_extension, public, sources, testonly, visibility
+```
+### <a name="target"></a>**target**: Declare an target with the given programmatic type.
+
+```
+  target(target_type_string, target_name_string) { ... }
+
+  The target() function is a way to invoke a built-in target or template with a
+  type determined at runtime. This is useful for cases where the type of a
+  target might not be known statically.
+
+  Only templates and built-in target functions are supported for the
+  target_type_string parameter. Arbitrary functions, configs, and toolchains
+  are not supported.
+
+  The call:
+    target("source_set", "doom_melon") {
+  Is equivalent to:
+    source_set("doom_melon") {
+```
+
+#### **Example**
+
+```
+  if (foo_build_as_shared) {
+    my_type = "shared_library"
+  } else {
+    my_type = "source_set"
+  }
+
+  target(my_type, "foo") {
+    ...
+  }
+```
+## <a name="functions"></a>Buildfile functions
+
+### <a name="assert"></a>**assert**: Assert an expression is true at generation time.
+
+```
+  assert(<condition> [, <error string>])
+
+  If the condition is false, the build will fail with an error. If the
+  optional second argument is provided, that string will be printed
+  with the error message.
+```
+
+#### **Examples**
+
+```
+  assert(is_win)
+  assert(defined(sources), "Sources must be defined");
+```
+### <a name="config"></a>**config**: Defines a configuration object.
+
+```
+  Configuration objects can be applied to targets and specify sets of compiler
+  flags, includes, defines, etc. They provide a way to conveniently group sets
+  of this configuration information.
+
+  A config is referenced by its label just like a target.
+
+  The values in a config are additive only. If you want to remove a flag you
+  need to remove the corresponding config that sets it. The final set of flags,
+  defines, etc. for a target is generated in this order:
+
+   1. The values specified directly on the target (rather than using a config.
+   2. The configs specified in the target's "configs" list, in order.
+   3. Public_configs from a breadth-first traversal of the dependency tree in
+      the order that the targets appear in "deps".
+   4. All dependent configs from a breadth-first traversal of the dependency
+      tree in the order that the targets appear in "deps".
+```
+
+#### **Variables valid in a config definition**
+```
+  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
+         asmflags, defines, include_dirs, inputs, ldflags, lib_dirs,
+         libs, precompiled_header, precompiled_source
+  Nested configs: configs
+```
+
+#### **Variables on a target used to apply configs**
+
+```
+  all_dependent_configs, configs, public_configs
+```
+
+#### **Example**
+
+```
+  config("myconfig") {
+    includes = [ "include/common" ]
+    defines = [ "ENABLE_DOOM_MELON" ]
+  }
+
+  executable("mything") {
+    configs = [ ":myconfig" ]
+  }
+```
+### <a name="declare_args"></a>**declare_args**: Declare build arguments.
+
+```
+  Introduces the given arguments into the current scope. If they are not
+  specified on the command line or in a toolchain's arguments, the default
+  values given in the declare_args block will be used. However, these defaults
+  will not override command-line values.
+
+  See also "gn help buildargs" for an overview.
+
+  The precise behavior of declare args is:
+
+   1. The declare_args() block executes. Any variable defined in the enclosing
+      scope is available for reading, but any variable defined earlier in
+      the current scope is not (since the overrides haven't been applied yet).
+
+   2. At the end of executing the block, any variables set within that scope
+      are saved globally as build arguments, with their current values being
+      saved as the "default value" for that argument.
+
+   3. User-defined overrides are applied. Anything set in "gn args" now
+      overrides any default values. The resulting set of variables is promoted
+      to be readable from the following code in the file.
+
+  This has some ramifications that may not be obvious:
+
+    - You should not perform difficult work inside a declare_args block since
+      this only sets a default value that may be discarded. In particular,
+      don't use the result of exec_script() to set the default value. If you
+      want to have a script-defined default, set some default "undefined" value
+      like [], "", or -1, and after the declare_args block, call exec_script if
+      the value is unset by the user.
+
+    - Because you cannot read the value of a variable defined in the same
+      block, if you need to make the default value of one arg depend
+      on the possibly-overridden value of another, write two separate
+      declare_args() blocks:
+
+        declare_args() {
+          enable_foo = true
+        }
+        declare_args() {
+          # Bar defaults to same user-overridden state as foo.
+          enable_bar = enable_foo
+        }
+```
+
+#### **Example**
+
+```
+  declare_args() {
+    enable_teleporter = true
+    enable_doom_melon = false
+  }
+
+  If you want to override the (default disabled) Doom Melon:
+    gn --args="enable_doom_melon=true enable_teleporter=true"
+  This also sets the teleporter, but it's already defaulted to on so it will
+  have no effect.
+```
+### <a name="defined"></a>**defined**: Returns whether an identifier is defined.
+
+```
+  Returns true if the given argument is defined. This is most useful in
+  templates to assert that the caller set things up properly.
+
+  You can pass an identifier:
+    defined(foo)
+  which will return true or false depending on whether foo is defined in the
+  current scope.
+
+  You can also check a named scope:
+    defined(foo.bar)
+  which will return true or false depending on whether bar is defined in the
+  named scope foo. It will throw an error if foo is not defined or is not a
+  scope.
+```
+
+#### **Example**
+
+```
+  template("mytemplate") {
+    # To help users call this template properly...
+    assert(defined(invoker.sources), "Sources must be defined")
+
+    # If we want to accept an optional "values" argument, we don't
+    # want to dereference something that may not be defined.
+    if (defined(invoker.values)) {
+      values = invoker.values
+    } else {
+      values = "some default value"
+    }
+  }
+```
+### <a name="exec_script"></a>**exec_script**: Synchronously run a script and return the output.
+
+```
+  exec_script(filename,
+              arguments = [],
+              input_conversion = "",
+              file_dependencies = [])
+
+  Runs the given script, returning the stdout of the script. The build
+  generation will fail if the script does not exist or returns a nonzero exit
+  code.
+
+  The current directory when executing the script will be the root build
+  directory. If you are passing file names, you will want to use the
+  rebase_path() function to make file names relative to this path (see "gn help
+  rebase_path").
+```
+
+#### **Arguments**:
+
+```
+  filename:
+      File name of python script to execute. Non-absolute names will be treated
+      as relative to the current build file.
+
+  arguments:
+      A list of strings to be passed to the script as arguments. May be
+      unspecified or the empty list which means no arguments.
+
+  input_conversion:
+      Controls how the file is read and parsed. See "gn help input_conversion".
+
+      If unspecified, defaults to the empty string which causes the script
+      result to be discarded. exec script will return None.
+
+  dependencies:
+      (Optional) A list of files that this script reads or otherwise depends
+      on. These dependencies will be added to the build result such that if any
+      of them change, the build will be regenerated and the script will be
+      re-run.
+
+      The script itself will be an implicit dependency so you do not need to
+      list it.
+```
+
+#### **Example**
+
+```
+  all_lines = exec_script(
+      "myscript.py", [some_input], "list lines",
+      [ rebase_path("data_file.txt", root_build_dir) ])
+
+  # This example just calls the script with no arguments and discards the
+  # result.
+  exec_script("//foo/bar/myscript.py")
+```
+### <a name="foreach"></a>**foreach**: Iterate over a list.
+
+```
+    foreach(<loop_var>, <list>) {
+      <loop contents>
+    }
+
+  Executes the loop contents block over each item in the list, assigning the
+  loop_var to each item in sequence. The <loop_var> will be a copy so assigning
+  to it will not mutate the list. The loop will iterate over a copy of <list>
+  so mutating it inside the loop will not affect iteration.
+
+  The block does not introduce a new scope, so that variable assignments inside
+  the loop will be visible once the loop terminates.
+
+  The loop variable will temporarily shadow any existing variables with the
+  same name for the duration of the loop. After the loop terminates the loop
+  variable will no longer be in scope, and the previous value (if any) will be
+  restored.
+```
+
+#### **Example**
+
+```
+  mylist = [ "a", "b", "c" ]
+  foreach(i, mylist) {
+    print(i)
+  }
+
+  Prints:
+  a
+  b
+  c
+```
+### <a name="forward_variables_from"></a>**forward_variables_from**: Copies variables from a different scope.
+
+```
+  forward_variables_from(from_scope, variable_list_or_star,
+                         variable_to_not_forward_list = [])
+
+  Copies the given variables from the given scope to the local scope if they
+  exist. This is normally used in the context of templates to use the values of
+  variables defined in the template invocation to a template-defined target.
+
+  The variables in the given variable_list will be copied if they exist in the
+  given scope or any enclosing scope. If they do not exist, nothing will happen
+  and they be left undefined in the current scope.
+
+  As a special case, if the variable_list is a string with the value of "*",
+  all variables from the given scope will be copied. "*" only copies variables
+  set directly on the from_scope, not enclosing ones. Otherwise it would
+  duplicate all global variables.
+
+  When an explicit list of variables is supplied, if the variable exists in the
+  current (destination) scope already, an error will be thrown. If "*" is
+  specified, variables in the current scope will be clobbered (the latter is
+  important because most targets have an implicit configs list, which means it
+  wouldn't work at all if it didn't clobber).
+
+  The sources assignment filter (see "gn help set_sources_assignment_filter")
+  is never applied by this function. It's assumed than any desired filtering
+  was already done when sources was set on the from_scope.
+
+  If variables_to_not_forward_list is non-empty, then it must contains a list
+  of variable names that will not be forwarded. This is mostly useful when
+  variable_list_or_star has a value of "*".
+```
+
+#### **Examples**
+
+```
+  # This is a common action template. It would invoke a script with some given
+  # parameters, and wants to use the various types of deps and the visibility
+  # from the invoker if it's defined. It also injects an additional dependency
+  # to all targets.
+  template("my_test") {
+    action(target_name) {
+      forward_variables_from(invoker, [ "data_deps", "deps",
+                                        "public_deps", "visibility" "
+                                                                    "])
+      # Add our test code to the dependencies.
+      # "deps" may or may not be defined at this point.
+      if (defined(deps)) {
+        deps += [ "//tools/doom_melon" ]
+      } else {
+        deps = [ "//tools/doom_melon" ]
+      }
+    }
+  }
+
+  # This is a template around either a target whose type depends on a global
+  # variable. It forwards all values from the invoker.
+  template("my_wrapper") {
+    target(my_wrapper_target_type, target_name) {
+      forward_variables_from(invoker, "*")
+    }
+  }
+
+  # A template that wraps another. It adds behavior based on one
+  # variable, and forwards all others to the nested target.
+  template("my_ios_test_app") {
+    ios_test_app(target_name) {
+      forward_variables_from(invoker, "*", ["test_bundle_name"])
+      if (!defined(extra_substitutions)) {
+        extra_substitutions = []
+      }
+      extra_substitutions += [ "BUNDLE_ID_TEST_NAME=$test_bundle_name" ]
+    }
+  }
+```
+### <a name="get_label_info"></a>**get_label_info**: Get an attribute from a target's label.
+
+```
+  get_label_info(target_label, what)
+
+  Given the label of a target, returns some attribute of that target. The
+  target need not have been previously defined in the same file, since none of
+  the attributes depend on the actual target definition, only the label itself.
+
+  See also "gn help get_target_outputs".
+```
+
+#### **Possible values for the "what" parameter**
+
+```
+  "name"
+      The short name of the target. This will match the value of the
+      "target_name" variable inside that target's declaration. For the label
+      "//foo/bar:baz" this will return "baz".
+
+  "dir"
+      The directory containing the target's definition, with no slash at the
+      end. For the label "//foo/bar:baz" this will return "//foo/bar".
+
+  "target_gen_dir"
+      The generated file directory for the target. This will match the value of
+      the "target_gen_dir" variable when inside that target's declaration.
+
+  "root_gen_dir"
+      The root of the generated file tree for the target. This will match the
+      value of the "root_gen_dir" variable when inside that target's
+      declaration.
+
+  "target_out_dir
+      The output directory for the target. This will match the value of the
+      "target_out_dir" variable when inside that target's declaration.
+
+  "root_out_dir"
+      The root of the output file tree for the target. This will match the
+      value of the "root_out_dir" variable when inside that target's
+      declaration.
+
+  "label_no_toolchain"
+      The fully qualified version of this label, not including the toolchain.
+      For the input ":bar" it might return "//foo:bar".
+
+  "label_with_toolchain"
+      The fully qualified version of this label, including the toolchain. For
+      the input ":bar" it might return "//foo:bar(//toolchain:x64)".
+
+  "toolchain"
+      The label of the toolchain. This will match the value of the
+      "current_toolchain" variable when inside that target's declaration.
+```
+
+#### **Examples**
+
+```
+  get_label_info(":foo", "name")
+  # Returns string "foo".
+
+  get_label_info("//foo/bar:baz", "target_gen_dir")
+  # Returns string "//out/Debug/gen/foo/bar".
+```
+### <a name="get_path_info"></a>**get_path_info**: Extract parts of a file or directory name.
+
+```
+  get_path_info(input, what)
+
+  The first argument is either a string representing a file or directory name,
+  or a list of such strings. If the input is a list the return value will be a
+  list containing the result of applying the rule to each item in the input.
+```
+
+#### **Possible values for the "what" parameter**
+
+```
+  "file"
+      The substring after the last slash in the path, including the name and
+      extension. If the input ends in a slash, the empty string will be
+      returned.
+        "foo/bar.txt" => "bar.txt"
+        "bar.txt" => "bar.txt"
+        "foo/" => ""
+        "" => ""
+
+  "name"
+     The substring of the file name not including the extension.
+        "foo/bar.txt" => "bar"
+        "foo/bar" => "bar"
+        "foo/" => ""
+
+  "extension"
+      The substring following the last period following the last slash, or the
+      empty string if not found. The period is not included.
+        "foo/bar.txt" => "txt"
+        "foo/bar" => ""
+
+  "dir"
+      The directory portion of the name, not including the slash.
+        "foo/bar.txt" => "foo"
+        "//foo/bar" => "//foo"
+        "foo" => "."
+
+      The result will never end in a slash, so if the resulting is empty, the
+      system ("/") or source ("//") roots, a "." will be appended such that it
+      is always legal to append a slash and a filename and get a valid path.
+
+  "out_dir"
+      The output file directory corresponding to the path of the given file,
+      not including a trailing slash.
+        "//foo/bar/baz.txt" => "//out/Default/obj/foo/bar"
+
+  "gen_dir"
+      The generated file directory corresponding to the path of the given file,
+      not including a trailing slash.
+        "//foo/bar/baz.txt" => "//out/Default/gen/foo/bar"
+
+  "abspath"
+      The full absolute path name to the file or directory. It will be resolved
+      relative to the current directory, and then the source- absolute version
+      will be returned. If the input is system- absolute, the same input will
+      be returned.
+        "foo/bar.txt" => "//mydir/foo/bar.txt"
+        "foo/" => "//mydir/foo/"
+        "//foo/bar" => "//foo/bar"  (already absolute)
+        "/usr/include" => "/usr/include"  (already absolute)
+
+      If you want to make the path relative to another directory, or to be
+      system-absolute, see rebase_path().
+```
+
+#### **Examples**
+```
+  sources = [ "foo.cc", "foo.h" ]
+  result = get_path_info(source, "abspath")
+  # result will be [ "//mydir/foo.cc", "//mydir/foo.h" ]
+
+  result = get_path_info("//foo/bar/baz.cc", "dir")
+  # result will be "//foo/bar"
+
+  # Extract the source-absolute directory name,
+  result = get_path_info(get_path_info(path, "dir"), "abspath"
+```
+### <a name="get_target_outputs"></a>**get_target_outputs**: [file list] Get the list of outputs from a target.
+
+```
+  get_target_outputs(target_label)
+
+  Returns a list of output files for the named target. The named target must
+  have been previously defined in the current file before this function is
+  called (it can't reference targets in other files because there isn't a
+  defined execution order, and it obviously can't reference targets that are
+  defined after the function call).
+
+  Only copy and action targets are supported. The outputs from binary targets
+  will depend on the toolchain definition which won't necessarily have been
+  loaded by the time a given line of code has run, and source sets and groups
+  have no useful output file.
+```
+
+#### **Return value**
+
+```
+  The names in the resulting list will be absolute file paths (normally like
+  "//out/Debug/bar.exe", depending on the build directory).
+
+  action targets: this will just return the files specified in the "outputs"
+  variable of the target.
+
+  action_foreach targets: this will return the result of applying the output
+  template to the sources (see "gn help source_expansion"). This will be the
+  same result (though with guaranteed absolute file paths), as
+  process_file_template will return for those inputs (see "gn help
+  process_file_template").
+
+  binary targets (executables, libraries): this will return a list of the
+  resulting binary file(s). The "main output" (the actual binary or library)
+  will always be the 0th element in the result. Depending on the platform and
+  output type, there may be other output files as well (like import libraries)
+  which will follow.
+
+  source sets and groups: this will return a list containing the path of the
+  "stamp" file that Ninja will produce once all outputs are generated. This
+  probably isn't very useful.
+```
+
+#### **Example**
+
+```
+  # Say this action generates a bunch of C source files.
+  action_foreach("my_action") {
+    sources = [ ... ]
+    outputs = [ ... ]
+  }
+
+  # Compile the resulting source files into a source set.
+  source_set("my_lib") {
+    sources = get_target_outputs(":my_action")
+  }
+```
+### <a name="getenv"></a>**getenv**: Get an environment variable.
+
+```
+  value = getenv(env_var_name)
+
+  Returns the value of the given environment variable. If the value is not
+  found, it will try to look up the variable with the "opposite" case (based on
+  the case of the first letter of the variable), but is otherwise
+  case-sensitive.
+
+  If the environment variable is not found, the empty string will be returned.
+  Note: it might be nice to extend this if we had the concept of "none" in the
+  language to indicate lookup failure.
+```
+
+#### **Example**
+
+```
+  home_dir = getenv("HOME")
+```
+### <a name="import"></a>**import**: Import a file into the current scope.
+
+```
+  The import command loads the rules and variables resulting from executing the
+  given file into the current scope.
+
+  By convention, imported files are named with a .gni extension.
+
+  An import is different than a C++ "include". The imported file is executed in
+  a standalone environment from the caller of the import command. The results
+  of this execution are cached for other files that import the same .gni file.
+
+  Note that you can not import a BUILD.gn file that's otherwise used in the
+  build. Files must either be imported or implicitly loaded as a result of deps
+  rules, but not both.
+
+  The imported file's scope will be merged with the scope at the point import
+  was called. If there is a conflict (both the current scope and the imported
+  file define some variable or rule with the same name but different value), a
+  runtime error will be thrown. Therefore, it's good practice to minimize the
+  stuff that an imported file defines.
+
+  Variables and templates beginning with an underscore '_' are considered
+  private and will not be imported. Imported files can use such variables for
+  internal computation without affecting other files.
+```
+
+#### **Examples**
+
+```
+  import("//build/rules/idl_compilation_rule.gni")
+
+  # Looks in the current directory.
+  import("my_vars.gni")
+```
+### <a name="not_needed"></a>**not_needed**: Mark variables from scope as not needed.
+
+```
+  not_needed(variable_list_or_star, variable_to_ignore_list = [])
+  not_needed(from_scope, variable_list_or_star,
+             variable_to_ignore_list = [])
+
+  Mark the variables in the current or given scope as not needed, which means
+  you will not get an error about unused variables for these. The
+  variable_to_ignore_list allows excluding variables from "all matches" if
+  variable_list_or_star is "*".
+```
+
+#### **Example**
+
+```
+  not_needed("*", [ "config" ])
+  not_needed([ "data_deps", "deps" ])
+  not_needed(invoker, "*", [ "config" ])
+  not_needed(invoker, [ "data_deps", "deps" ])
+```
+### <a name="pool"></a>**pool**: Defines a pool object.
+
+```
+  Pool objects can be applied to a tool to limit the parallelism of the
+  build. This object has a single property "depth" corresponding to
+  the number of tasks that may run simultaneously.
+
+  As the file containing the pool definition may be executed in the
+  context of more than one toolchain it is recommended to specify an
+  explicit toolchain when defining and referencing a pool.
+
+  A pool is referenced by its label just like a target.
+```
+
+#### **Variables**
+
+```
+  depth*
+  * = required
+```
+
+#### **Example**
+
+```
+  if (current_toolchain == default_toolchain) {
+    pool("link_pool") {
+      depth = 1
+    }
+  }
+
+  toolchain("toolchain") {
+    tool("link") {
+      command = "..."
+      pool = ":link_pool($default_toolchain)")
+    }
+  }
+```
+### <a name="print"></a>**print**: Prints to the console.
+
+```
+  Prints all arguments to the console separated by spaces. A newline is
+  automatically appended to the end.
+
+  This function is intended for debugging. Note that build files are run in
+  parallel so you may get interleaved prints. A buildfile may also be executed
+  more than once in parallel in the context of different toolchains so the
+  prints from one file may be duplicated or
+  interleaved with itself.
+```
+
+#### **Examples**
+
+```
+  print("Hello world")
+
+  print(sources, deps)
+```
+### <a name="process_file_template"></a>**process_file_template**: Do template expansion over a list of files.
+
+```
+  process_file_template(source_list, template)
+
+  process_file_template applies a template list to a source file list,
+  returning the result of applying each template to each source. This is
+  typically used for computing output file names from input files.
+
+  In most cases, get_target_outputs() will give the same result with shorter,
+  more maintainable code. This function should only be used when that function
+  can't be used (like there's no target or the target is defined in another
+  build file).
+```
+
+#### **Arguments**
+
+```
+  The source_list is a list of file names.
+
+  The template can be a string or a list. If it is a list, multiple output
+  strings are generated for each input.
+
+  The template should contain source expansions to which each name in the
+  source list is applied. See "gn help source_expansion".
+```
+
+#### **Example**
+
+```
+  sources = [
+    "foo.idl",
+    "bar.idl",
+  ]
+  myoutputs = process_file_template(
+      sources,
+      [ "$target_gen_dir/{{source_name_part}}.cc",
+        "$target_gen_dir/{{source_name_part}}.h" ])
+
+ The result in this case will be:
+    [ "//out/Debug/foo.cc"
+      "//out/Debug/foo.h"
+      "//out/Debug/bar.cc"
+      "//out/Debug/bar.h" ]
+```
+### <a name="read_file"></a>**read_file**: Read a file into a variable.
+
+```
+  read_file(filename, input_conversion)
+
+  Whitespace will be trimmed from the end of the file. Throws an error if the
+  file can not be opened.
+```
+
+#### **Arguments**
+
+```
+  filename
+      Filename to read, relative to the build file.
+
+  input_conversion
+      Controls how the file is read and parsed. See "gn help input_conversion".
+```
+
+#### **Example**
+
+```
+  lines = read_file("foo.txt", "list lines")
+```
+### <a name="rebase_path"></a>**rebase_path**: Rebase a file or directory to another location.
+
+```
+  converted = rebase_path(input,
+                          new_base = "",
+                          current_base = ".")
+
+  Takes a string argument representing a file name, or a list of such strings
+  and converts it/them to be relative to a different base directory.
+
+  When invoking the compiler or scripts, GN will automatically convert sources
+  and include directories to be relative to the build directory. However, if
+  you're passing files directly in the "args" array or doing other manual
+  manipulations where GN doesn't know something is a file name, you will need
+  to convert paths to be relative to what your tool is expecting.
+
+  The common case is to use this to convert paths relative to the current
+  directory to be relative to the build directory (which will be the current
+  directory when executing scripts).
+
+  If you want to convert a file path to be source-absolute (that is, beginning
+  with a double slash like "//foo/bar"), you should use the get_path_info()
+  function. This function won't work because it will always make relative
+  paths, and it needs to support making paths relative to the source root, so
+  can't also generate source-absolute paths without more special-cases.
+```
+
+#### **Arguments**
+
+```
+  input
+      A string or list of strings representing file or directory names These
+      can be relative paths ("foo/bar.txt"), system absolute paths
+      ("/foo/bar.txt"), or source absolute paths ("//foo/bar.txt").
+
+  new_base
+      The directory to convert the paths to be relative to. This can be an
+      absolute path or a relative path (which will be treated as being relative
+      to the current BUILD-file's directory).
+
+      As a special case, if new_base is the empty string (the default), all
+      paths will be converted to system-absolute native style paths with system
+      path separators. This is useful for invoking external programs.
+
+  current_base
+      Directory representing the base for relative paths in the input. If this
+      is not an absolute path, it will be treated as being relative to the
+      current build file. Use "." (the default) to convert paths from the
+      current BUILD-file's directory.
+```
+
+#### **Return value**
+
+```
+  The return value will be the same type as the input value (either a string or
+  a list of strings). All relative and source-absolute file names will be
+  converted to be relative to the requested output System-absolute paths will
+  be unchanged.
+
+  Whether an output path will end in a slash will match whether the
+  corresponding input path ends in a slash. It will return "." or "./"
+  (depending on whether the input ends in a slash) to avoid returning empty
+  strings. This means if you want a root path ("//" or "/") not ending in a
+  slash, you can add a dot ("//.").
+```
+
+#### **Example**
+
+```
+  # Convert a file in the current directory to be relative to the build
+  # directory (the current dir when executing compilers and scripts).
+  foo = rebase_path("myfile.txt", root_build_dir)
+  # might produce "../../project/myfile.txt".
+
+  # Convert a file to be system absolute:
+  foo = rebase_path("myfile.txt")
+  # Might produce "D:\\source\\project\\myfile.txt" on Windows or
+  # "/home/you/source/project/myfile.txt" on Linux.
+
+  # Typical usage for converting to the build directory for a script.
+  action("myscript") {
+    # Don't convert sources, GN will automatically convert these to be relative
+    # to the build directory when it constructs the command line for your
+    # script.
+    sources = [ "foo.txt", "bar.txt" ]
+
+    # Extra file args passed manually need to be explicitly converted
+    # to be relative to the build directory:
+    args = [
+      "--data",
+      rebase_path("//mything/data/input.dat", root_build_dir),
+      "--rel",
+      rebase_path("relative_path.txt", root_build_dir)
+    ] + rebase_path(sources, root_build_dir)
+  }
+```
+### <a name="set_default_toolchain"></a>**set_default_toolchain**: Sets the default toolchain name.
+
+```
+  set_default_toolchain(toolchain_label)
+
+  The given label should identify a toolchain definition (see "gn help
+  toolchain"). This toolchain will be used for all targets unless otherwise
+  specified.
+
+  This function is only valid to call during the processing of the build
+  configuration file. Since the build configuration file is processed
+  separately for each toolchain, this function will be a no-op when called
+  under any non-default toolchains.
+
+  For example, the default toolchain should be appropriate for the current
+  environment. If the current environment is 32-bit and somebody references a
+  target with a 64-bit toolchain, we wouldn't want processing of the build
+  config file for the 64-bit toolchain to reset the default toolchain to
+  64-bit, we want to keep it 32-bits.
+```
+
+#### **Argument**
+
+```
+  toolchain_label
+      Toolchain name.
+```
+
+#### **Example**
+
+```
+  # Set default toolchain only has an effect when run in the context of the
+  # default toolchain. Pick the right one according to the current CPU
+  # architecture.
+  if (target_cpu == "x64") {
+    set_default_toolchain("//toolchains:64")
+  } else if (target_cpu == "x86") {
+    set_default_toolchain("//toolchains:32")
+  }
+```
+### <a name="set_defaults"></a>**set_defaults**: Set default values for a target type.
+
+```
+  set_defaults(<target_type_name>) { <values...> }
+
+  Sets the default values for a given target type. Whenever target_type_name is
+  seen in the future, the values specified in set_default's block will be
+  copied into the current scope.
+
+  When the target type is used, the variable copying is very strict. If a
+  variable with that name is already in scope, the build will fail with an
+  error.
+
+  set_defaults can be used for built-in target types ("executable",
+  "shared_library", etc.) and custom ones defined via the "template" command.
+  It can be called more than once and the most recent call in any scope will
+  apply, but there is no way to refer to the previous defaults and modify them
+  (each call to set_defaults must supply a complete list of all defaults it
+  wants). If you want to share defaults, store them in a separate variable.
+```
+
+#### **Example**
+
+```
+  set_defaults("static_library") {
+    configs = [ "//tools/mything:settings" ]
+  }
+
+  static_library("mylib")
+    # The configs will be auto-populated as above. You can remove it if
+    # you don't want the default for a particular default:
+    configs -= [ "//tools/mything:settings" ]
+  }
+```
+### <a name="set_sources_assignment_filter"></a>**set_sources_assignment_filter**: Set a pattern to filter source files.
+
+```
+  The sources assignment filter is a list of patterns that remove files from
+  the list implicitly whenever the "sources" variable is assigned to. This will
+  do nothing for non-lists.
+
+  This is intended to be used to globally filter out files with
+  platform-specific naming schemes when they don't apply, for example you may
+  want to filter out all "*_win.cc" files on non-Windows platforms.
+
+  Typically this will be called once in the master build config script to set
+  up the filter for the current platform. Subsequent calls will overwrite the
+  previous values.
+
+  If you want to bypass the filter and add a file even if it might be filtered
+  out, call set_sources_assignment_filter([]) to clear the list of filters.
+  This will apply until the current scope exits
+```
+
+#### **How to use patterns**
+
+```
+  File patterns are VERY limited regular expressions. They must match the
+  entire input string to be counted as a match. In regular expression parlance,
+  there is an implicit "^...$" surrounding your input. If you want to match a
+  substring, you need to use wildcards at the beginning and end.
+
+  There are only two special tokens understood by the pattern matcher.
+  Everything else is a literal.
+
+   - "*" Matches zero or more of any character. It does not depend on the
+     preceding character (in regular expression parlance it is equivalent to
+     ".*").
+
+   - "\b" Matches a path boundary. This will match the beginning or end of a
+     string, or a slash.
+```
+
+#### **Pattern examples**
+
+```
+  "*asdf*"
+      Matches a string containing "asdf" anywhere.
+
+  "asdf"
+      Matches only the exact string "asdf".
+
+  "*.cc"
+      Matches strings ending in the literal ".cc".
+
+  "\bwin/*"
+      Matches "win/foo" and "foo/win/bar.cc" but not "iwin/foo".
+```
+
+#### **Sources assignment example**
+
+```
+  # Filter out all _win files.
+  set_sources_assignment_filter([ "*_win.cc", "*_win.h" ])
+  sources = [ "a.cc", "b_win.cc" ]
+  print(sources)
+  # Will print [ "a.cc" ]. b_win one was filtered out.
+```
+### <a name="split_list"></a>**split_list**: Splits a list into N different sub-lists.
+
+```
+  result = split_list(input, n)
+
+  Given a list and a number N, splits the list into N sub-lists of
+  approximately equal size. The return value is a list of the sub-lists. The
+  result will always be a list of size N. If N is greater than the number of
+  elements in the input, it will be padded with empty lists.
+
+  The expected use is to divide source files into smaller uniform chunks.
+```
+
+#### **Example**
+
+```
+  The code:
+    mylist = [1, 2, 3, 4, 5, 6]
+    print(split_list(mylist, 3))
+
+  Will print:
+    [[1, 2], [3, 4], [5, 6]
+```
+### <a name="template"></a>**template**: Define a template rule.
+
+```
+  A template defines a custom name that acts like a function. It provides a way
+  to add to the built-in target types.
+
+  The template() function is used to declare a template. To invoke the
+  template, just use the name of the template like any other target type.
+
+  Often you will want to declare your template in a special file that other
+  files will import (see "gn help import") so your template rule can be shared
+  across build files.
+```
+
+#### **Variables and templates**:
+
+```
+  When you call template() it creates a closure around all variables currently
+  in scope with the code in the template block. When the template is invoked,
+  the closure will be executed.
+
+  When the template is invoked, the code in the caller is executed and passed
+  to the template code as an implicit "invoker" variable. The template uses
+  this to read state out of the invoking code.
+
+  One thing explicitly excluded from the closure is the "current directory"
+  against which relative file names are resolved. The current directory will be
+  that of the invoking code, since typically that code specifies the file
+  names. This means all files internal to the template should use absolute
+  names.
+
+  A template will typically forward some or all variables from the invoking
+  scope to a target that it defines. Often, such variables might be optional.
+  Use the pattern:
+
+    if (defined(invoker.deps)) {
+      deps = invoker.deps
+    }
+
+  The function forward_variables_from() provides a shortcut to forward one or
+  more or possibly all variables in this manner:
+
+    forward_variables_from(invoker, ["deps", "public_deps"])
+```
+
+#### **Target naming**
+
+```
+  Your template should almost always define a built-in target with the name the
+  template invoker specified. For example, if you have an IDL template and
+  somebody does:
+    idl("foo") {...
+  you will normally want this to expand to something defining a source_set or
+  static_library named "foo" (among other things you may need). This way, when
+  another target specifies a dependency on "foo", the static_library or
+  source_set will be linked.
+
+  It is also important that any other targets your template expands to have
+  unique names, or you will get collisions.
+
+  Access the invoking name in your template via the implicit "target_name"
+  variable. This should also be the basis for how other targets that a template
+  expands to ensure uniqueness.
+
+  A typical example would be a template that defines an action to generate some
+  source files, and a source_set to compile that source. Your template would
+  name the source_set "target_name" because that's what you want external
+  targets to depend on to link your code. And you would name the action
+  something like "${target_name}_action" to make it unique. The source set
+  would have a dependency on the action to make it run.
+```
+
+#### **Overriding builtin targets**
+
+```
+  You can use template to redefine a built-in target in which case your template
+  takes a precedence over the built-in one. All uses of the target from within
+  the template definition will refer to the built-in target which makes it
+  possible to extend the behavior of the built-in target:
+
+    template("shared_library") {
+      shared_library(shlib) {
+        forward_variables_from(invoker, [ "*" ])
+        ...
+      }
+    }
+```
+
+#### **Example of defining a template**
+
+```
+  template("my_idl") {
+    # Be nice and help callers debug problems by checking that the variables
+    # the template requires are defined. This gives a nice message rather than
+    # giving the user an error about an undefined variable in the file defining
+    # the template
+    #
+    # You can also use defined() to give default values to variables
+    # unspecified by the invoker.
+    assert(defined(invoker.sources),
+           "Need sources in $target_name listing the idl files.")
+
+    # Name of the intermediate target that does the code gen. This must
+    # incorporate the target name so it's unique across template
+    # instantiations.
+    code_gen_target_name = target_name + "_code_gen"
+
+    # Intermediate target to convert IDL to C source. Note that the name is
+    # based on the name the invoker of the template specified. This way, each
+    # time the template is invoked we get a unique intermediate action name
+    # (since all target names are in the global scope).
+    action_foreach(code_gen_target_name) {
+      # Access the scope defined by the invoker via the implicit "invoker"
+      # variable.
+      sources = invoker.sources
+
+      # Note that we need an absolute path for our script file name. The
+      # current directory when executing this code will be that of the invoker
+      # (this is why we can use the "sources" directly above without having to
+      # rebase all of the paths). But if we need to reference a script relative
+      # to the template file, we'll need to use an absolute path instead.
+      script = "//tools/idl/idl_code_generator.py"
+
+      # Tell GN how to expand output names given the sources.
+      # See "gn help source_expansion" for more.
+      outputs = [ "$target_gen_dir/{{source_name_part}}.cc",
+                  "$target_gen_dir/{{source_name_part}}.h" ]
+    }
+
+    # Name the source set the same as the template invocation so instancing
+    # this template produces something that other targets can link to in their
+    # deps.
+    source_set(target_name) {
+      # Generates the list of sources, we get these from the action_foreach
+      # above.
+      sources = get_target_outputs(":$code_gen_target_name")
+
+      # This target depends on the files produced by the above code gen target.
+      deps = [ ":$code_gen_target_name" ]
+    }
+  }
+```
+
+#### **Example of invoking the resulting template**
+
+```
+  # This calls the template code above, defining target_name to be
+  # "foo_idl_files" and "invoker" to be the set of stuff defined in the curly
+  # brackets.
+  my_idl("foo_idl_files") {
+    # Goes into the template as "invoker.sources".
+    sources = [ "foo.idl", "bar.idl" ]
+  }
+
+  # Here is a target that depends on our template.
+  executable("my_exe") {
+    # Depend on the name we gave the template call above. Internally, this will
+    # produce a dependency from executable to the source_set inside the
+    # template (since it has this name), which will in turn depend on the code
+    # gen action.
+    deps = [ ":foo_idl_files" ]
+  }
+```
+### <a name="tool"></a>**tool**: Specify arguments to a toolchain tool.
+
+#### **Usage**
+
+```
+  tool(<tool type>) {
+    <tool variables...>
+  }
+```
+
+#### **Tool types**
+
+```
+    Compiler tools:
+      "cc": C compiler
+      "cxx": C++ compiler
+      "objc": Objective C compiler
+      "objcxx": Objective C++ compiler
+      "rc": Resource compiler (Windows .rc files)
+      "asm": Assembler
+
+    Linker tools:
+      "alink": Linker for static libraries (archives)
+      "solink": Linker for shared libraries
+      "link": Linker for executables
+
+    Other tools:
+      "stamp": Tool for creating stamp files
+      "copy": Tool to copy files.
+      "action": Defaults for actions
+
+    Platform specific tools:
+      "copy_bundle_data": [iOS, macOS] Tool to copy files in a bundle.
+      "compile_xcassets": [iOS, macOS] Tool to compile asset catalogs.
+```
+
+#### **Tool variables**
+
+```
+    command  [string with substitutions]
+        Valid for: all tools except "action" (required)
+
+        The command to run.
+
+    default_output_dir  [string with substitutions]
+        Valid for: linker tools
+
+        Default directory name for the output file relative to the
+        root_build_dir. It can contain other substitution patterns. This will
+        be the default value for the {{output_dir}} expansion (discussed below)
+        but will be overridden by the "output_dir" variable in a target, if one
+        is specified.
+
+        GN doesn't do anything with this string other than pass it along,
+        potentially with target-specific overrides. It is the tool's job to use
+        the expansion so that the files will be in the right place.
+
+    default_output_extension  [string]
+        Valid for: linker tools
+
+        Extension for the main output of a linkable tool. It includes the
+        leading dot. This will be the default value for the
+        {{output_extension}} expansion (discussed below) but will be overridden
+        by by the "output extension" variable in a target, if one is specified.
+        Empty string means no extension.
+
+        GN doesn't actually do anything with this extension other than pass it
+        along, potentially with target-specific overrides. One would typically
+        use the {{output_extension}} value in the "outputs" to read this value.
+
+        Example: default_output_extension = ".exe"
+
+    depfile  [string with substitutions]
+        Valid for: compiler tools (optional)
+
+        If the tool can write ".d" files, this specifies the name of the
+        resulting file. These files are used to list header file dependencies
+        (or other implicit input dependencies) that are discovered at build
+        time. See also "depsformat".
+
+        Example: depfile = "{{output}}.d"
+
+    depsformat  [string]
+        Valid for: compiler tools (when depfile is specified)
+
+        Format for the deps outputs. This is either "gcc" or "msvc". See the
+        ninja documentation for "deps" for more information.
+
+        Example: depsformat = "gcc"
+
+    description  [string with substitutions, optional]
+        Valid for: all tools
+
+        What to print when the command is run.
+
+        Example: description = "Compiling {{source}}"
+
+    lib_switch  [string, optional, link tools only]
+    lib_dir_switch  [string, optional, link tools only]
+        Valid for: Linker tools except "alink"
+
+        These strings will be prepended to the libraries and library search
+        directories, respectively, because linkers differ on how specify them.
+        If you specified:
+          lib_switch = "-l"
+          lib_dir_switch = "-L"
+        then the "{{libs}}" expansion for [ "freetype", "expat"] would be
+        "-lfreetype -lexpat".
+
+    outputs  [list of strings with substitutions]
+        Valid for: Linker and compiler tools (required)
+
+        An array of names for the output files the tool produces. These are
+        relative to the build output directory. There must always be at least
+        one output file. There can be more than one output (a linker might
+        produce a library and an import library, for example).
+
+        This array just declares to GN what files the tool will produce. It is
+        your responsibility to specify the tool command that actually produces
+        these files.
+
+        If you specify more than one output for shared library links, you
+        should consider setting link_output, depend_output, and
+        runtime_outputs.
+
+        Example for a compiler tool that produces .obj files:
+          outputs = [
+            "{{source_out_dir}}/{{source_name_part}}.obj"
+          ]
+
+        Example for a linker tool that produces a .dll and a .lib. The use of
+        {{target_output_name}}, {{output_extension}} and {{output_dir}} allows
+        the target to override these values.
+          outputs = [
+            "{{output_dir}}/{{target_output_name}}"
+                "{{output_extension}}",
+            "{{output_dir}}/{{target_output_name}}.lib",
+          ]
+
+    pool [label, optional]
+        Valid for: all tools (optional)
+
+        Label of the pool to use for the tool. Pools are used to limit the
+        number of tasks that can execute concurrently during the build.
+
+        See also "gn help pool".
+
+    link_output  [string with substitutions]
+    depend_output  [string with substitutions]
+        Valid for: "solink" only (optional)
+
+        These two files specify which of the outputs from the solink tool
+        should be used for linking and dependency tracking. These should match
+        entries in the "outputs". If unspecified, the first item in the
+        "outputs" array will be used for all. See "Separate linking and
+        dependencies for shared libraries" below for more.
+
+        On Windows, where the tools produce a .dll shared library and a .lib
+        import library, you will want the first two to be the import library
+        and the third one to be the .dll file. On Linux, if you're not doing
+        the separate linking/dependency optimization, all of these should be
+        the .so output.
+
+    output_prefix  [string]
+        Valid for: Linker tools (optional)
+
+        Prefix to use for the output name. Defaults to empty. This prefix will
+        be prepended to the name of the target (or the output_name if one is
+        manually specified for it) if the prefix is not already there. The
+        result will show up in the {{output_name}} substitution pattern.
+
+        Individual targets can opt-out of the output prefix by setting:
+          output_prefix_override = true
+        (see "gn help output_prefix_override").
+
+        This is typically used to prepend "lib" to libraries on
+        Posix systems:
+          output_prefix = "lib"
+
+    precompiled_header_type  [string]
+        Valid for: "cc", "cxx", "objc", "objcxx"
+
+        Type of precompiled headers. If undefined or the empty string,
+        precompiled headers will not be used for this tool. Otherwise use "gcc"
+        or "msvc".
+
+        For precompiled headers to be used for a given target, the target (or a
+        config applied to it) must also specify a "precompiled_header" and, for
+        "msvc"-style headers, a "precompiled_source" value. If the type is
+        "gcc", then both "precompiled_header" and "precompiled_source" must
+        resolve to the same file, despite the different formats required for
+        each."
+
+        See "gn help precompiled_header" for more.
+
+    restat  [boolean]
+        Valid for: all tools (optional, defaults to false)
+
+        Requests that Ninja check the file timestamp after this tool has run to
+        determine if anything changed. Set this if your tool has the ability to
+        skip writing output if the output file has not changed.
+
+        Normally, Ninja will assume that when a tool runs the output be new and
+        downstream dependents must be rebuild. When this is set to trye, Ninja
+        can skip rebuilding downstream dependents for input changes that don't
+        actually affect the output.
+
+        Example:
+          restat = true
+
+    rspfile  [string with substitutions]
+        Valid for: all tools except "action" (optional)
+
+        Name of the response file. If empty, no response file will be
+        used. See "rspfile_content".
+
+    rspfile_content  [string with substitutions]
+        Valid for: all tools except "action" (required when "rspfile" is used)
+
+        The contents to be written to the response file. This may include all
+        or part of the command to send to the tool which allows you to get
+        around OS command-line length limits.
+
+        This example adds the inputs and libraries to a response file, but
+        passes the linker flags directly on the command line:
+          tool("link") {
+            command = "link -o {{output}} {{ldflags}} @{{output}}.rsp"
+            rspfile = "{{output}}.rsp"
+            rspfile_content = "{{inputs}} {{solibs}} {{libs}}"
+          }
+
+    runtime_outputs  [string list with substitutions]
+        Valid for: linker tools
+
+        If specified, this list is the subset of the outputs that should be
+        added to runtime deps (see "gn help runtime_deps"). By default (if
+        runtime_outputs is empty or unspecified), it will be the link_output.
+```
+
+#### **Expansions for tool variables**
+
+```
+  All paths are relative to the root build directory, which is the current
+  directory for running all tools. These expansions are available to all tools:
+
+    {{label}}
+        The label of the current target. This is typically used in the
+        "description" field for link tools. The toolchain will be omitted from
+        the label for targets in the default toolchain, and will be included
+        for targets in other toolchains.
+
+    {{label_name}}
+        The short name of the label of the target. This is the part after the
+        colon. For "//foo/bar:baz" this will be "baz". Unlike
+        {{target_output_name}}, this is not affected by the "output_prefix" in
+        the tool or the "output_name" set on the target.
+
+    {{output}}
+        The relative path and name of the output(s) of the current build step.
+        If there is more than one output, this will expand to a list of all of
+        them. Example: "out/base/my_file.o"
+
+    {{target_gen_dir}}
+    {{target_out_dir}}
+        The directory of the generated file and output directories,
+        respectively, for the current target. There is no trailing slash. See
+        also {{output_dir}} for linker tools. Example: "out/base/test"
+
+    {{target_output_name}}
+        The short name of the current target with no path information, or the
+        value of the "output_name" variable if one is specified in the target.
+        This will include the "output_prefix" if any. See also {{label_name}}.
+
+        Example: "libfoo" for the target named "foo" and an output prefix for
+        the linker tool of "lib".
+
+  Compiler tools have the notion of a single input and a single output, along
+  with a set of compiler-specific flags. The following expansions are
+  available:
+
+    {{asmflags}}
+    {{cflags}}
+    {{cflags_c}}
+    {{cflags_cc}}
+    {{cflags_objc}}
+    {{cflags_objcc}}
+    {{defines}}
+    {{include_dirs}}
+        Strings correspond that to the processed flags/defines/include
+        directories specified for the target.
+        Example: "--enable-foo --enable-bar"
+
+        Defines will be prefixed by "-D" and include directories will be
+        prefixed by "-I" (these work with Posix tools as well as Microsoft
+        ones).
+
+    {{source}}
+        The relative path and name of the current input file.
+        Example: "../../base/my_file.cc"
+
+    {{source_file_part}}
+        The file part of the source including the extension (with no directory
+        information).
+        Example: "foo.cc"
+
+    {{source_name_part}}
+        The filename part of the source file with no directory or extension.
+        Example: "foo"
+
+    {{source_gen_dir}}
+    {{source_out_dir}}
+        The directory in the generated file and output directories,
+        respectively, for the current input file. If the source file is in the
+        same directory as the target is declared in, they will will be the same
+        as the "target" versions above. Example: "gen/base/test"
+
+  Linker tools have multiple inputs and (potentially) multiple outputs The
+  static library tool ("alink") is not considered a linker tool. The following
+  expansions are available:
+
+    {{inputs}}
+    {{inputs_newline}}
+        Expands to the inputs to the link step. This will be a list of object
+        files and static libraries.
+        Example: "obj/foo.o obj/bar.o obj/somelibrary.a"
+
+        The "_newline" version will separate the input files with newlines
+        instead of spaces. This is useful in response files: some linkers can
+        take a "-filelist" flag which expects newline separated files, and some
+        Microsoft tools have a fixed-sized buffer for parsing each line of a
+        response file.
+
+    {{ldflags}}
+        Expands to the processed set of ldflags and library search paths
+        specified for the target.
+        Example: "-m64 -fPIC -pthread -L/usr/local/mylib"
+
+    {{libs}}
+        Expands to the list of system libraries to link to. Each will be
+        prefixed by the "lib_switch".
+
+        As a special case to support Mac, libraries with names ending in
+        ".framework" will be added to the {{libs}} with "-framework" preceding
+        it, and the lib prefix will be ignored.
+
+        Example: "-lfoo -lbar"
+
+    {{output_dir}}
+        The value of the "output_dir" variable in the target, or the the value
+        of the "default_output_dir" value in the tool if the target does not
+        override the output directory. This will be relative to the
+        root_build_dir and will not end in a slash. Will be "." for output to
+        the root_build_dir.
+
+        This is subtly different than {{target_out_dir}} which is defined by GN
+        based on the target's path and not overridable. {{output_dir}} is for
+        the final output, {{target_out_dir}} is generally for object files and
+        other outputs.
+
+        Usually {{output_dir}} would be defined in terms of either
+        {{target_out_dir}} or {{root_out_dir}}
+
+    {{output_extension}}
+        The value of the "output_extension" variable in the target, or the
+        value of the "default_output_extension" value in the tool if the target
+        does not specify an output extension.
+        Example: ".so"
+
+    {{solibs}}
+        Extra libraries from shared library dependencies not specified in the
+        {{inputs}}. This is the list of link_output files from shared libraries
+        (if the solink tool specifies a "link_output" variable separate from
+        the "depend_output").
+
+        These should generally be treated the same as libs by your tool.
+
+        Example: "libfoo.so libbar.so"
+
+  The static library ("alink") tool allows {{arflags}} plus the common tool
+  substitutions.
+
+  The copy tool allows the common compiler/linker substitutions, plus
+  {{source}} which is the source of the copy. The stamp tool allows only the
+  common tool substitutions.
+
+  The copy_bundle_data and compile_xcassets tools only allows the common tool
+  substitutions. Both tools are required to create iOS/macOS bundles and need
+  only be defined on those platforms.
+
+  The copy_bundle_data tool will be called with one source and needs to copy
+  (optionally optimizing the data representation) to its output. It may be
+  called with a directory as input and it needs to be recursively copied.
+
+  The compile_xcassets tool will be called with one or more source (each an
+  asset catalog) that needs to be compiled to a single output. The following
+  substitutions are available:
+
+    {{inputs}}
+        Expands to the list of .xcassets to use as input to compile the asset
+        catalog.
+
+    {{bundle_product_type}}
+        Expands to the product_type of the bundle that will contain the
+        compiled asset catalog. Usually corresponds to the product_type
+        property of the corresponding create_bundle target.
+
+    {{bundle_partial_info_plist}}
+        Expands to the path to the partial Info.plist generated by the
+        assets catalog compiler. Usually based on the target_name of
+        the create_bundle target.
+```
+
+#### **Separate linking and dependencies for shared libraries**
+
+```
+  Shared libraries are special in that not all changes to them require that
+  dependent targets be re-linked. If the shared library is changed but no
+  imports or exports are different, dependent code needn't be relinked, which
+  can speed up the build.
+
+  If your link step can output a list of exports from a shared library and
+  writes the file only if the new one is different, the timestamp of this file
+  can be used for triggering re-links, while the actual shared library would be
+  used for linking.
+
+  You will need to specify
+    restat = true
+  in the linker tool to make this work, so Ninja will detect if the timestamp
+  of the dependency file has changed after linking (otherwise it will always
+  assume that running a command updates the output):
+
+    tool("solink") {
+      command = "..."
+      outputs = [
+        "{{output_dir}}/{{target_output_name}}{{output_extension}}",
+        "{{output_dir}}/{{target_output_name}}"
+            "{{output_extension}}.TOC",
+      ]
+      link_output =
+        "{{output_dir}}/{{target_output_name}}{{output_extension}}"
+      depend_output =
+        "{{output_dir}}/{{target_output_name}}"
+            "{{output_extension}}.TOC"
+      restat = true
+    }
+```
+
+#### **Example**
+
+```
+  toolchain("my_toolchain") {
+    # Put these at the top to apply to all tools below.
+    lib_switch = "-l"
+    lib_dir_switch = "-L"
+
+    tool("cc") {
+      command = "gcc {{source}} -o {{output}}"
+      outputs = [ "{{source_out_dir}}/{{source_name_part}}.o" ]
+      description = "GCC {{source}}"
+    }
+    tool("cxx") {
+      command = "g++ {{source}} -o {{output}}"
+      outputs = [ "{{source_out_dir}}/{{source_name_part}}.o" ]
+      description = "G++ {{source}}"
+    }
+  };
+```
+### <a name="toolchain"></a>**toolchain**: Defines a toolchain.
+
+```
+  A toolchain is a set of commands and build flags used to compile the source
+  code. The toolchain() function defines these commands.
+```
+
+#### **Toolchain overview**
+
+```
+  You can have more than one toolchain in use at once in a build and a target
+  can exist simultaneously in multiple toolchains. A build file is executed
+  once for each toolchain it is referenced in so the GN code can vary all
+  parameters of each target (or which targets exist) on a per-toolchain basis.
+
+  When you have a simple build with only one toolchain, the build config file
+  is loaded only once at the beginning of the build. It must call
+  set_default_toolchain() (see "gn help set_default_toolchain") to tell GN the
+  label of the toolchain definition to use. The "toolchain_args" section of the
+  toolchain definition is ignored.
+
+  When a target has a dependency on a target using different toolchain (see "gn
+  help labels" for how to specify this), GN will start a build using that
+  secondary toolchain to resolve the target. GN will load the build config file
+  with the build arguments overridden as specified in the toolchain_args.
+  Because the default toolchain is already known, calls to
+  set_default_toolchain() are ignored.
+
+  To load a file in an alternate toolchain, GN does the following:
+
+    1. Loads the file with the toolchain definition in it (as determined by the
+       toolchain label).
+    2. Re-runs the master build configuration file, applying the arguments
+       specified by the toolchain_args section of the toolchain definition.
+    3. Loads the destination build file in the context of the configuration file
+       in the previous step.
+
+  The toolchain configuration is two-way. In the default toolchain (i.e. the
+  main build target) the configuration flows from the build config file to the
+  toolchain. The build config file looks at the state of the build (OS type,
+  CPU architecture, etc.) and decides which toolchain to use (via
+  set_default_toolchain()). In secondary toolchains, the configuration flows
+  from the toolchain to the build config file: the "toolchain_args" in the
+  toolchain definition specifies the arguments to re-invoke the build.
+```
+
+#### **Functions and variables**
+
+```
+  tool()
+    The tool() function call specifies the commands commands to run for a given
+    step. See "gn help tool".
+
+  toolchain_args
+    Overrides for build arguments to pass to the toolchain when invoking it.
+    This is a variable of type "scope" where the variable names correspond to
+    variables in declare_args() blocks.
+
+    When you specify a target using an alternate toolchain, the master build
+    configuration file is re-interpreted in the context of that toolchain.
+    toolchain_args allows you to control the arguments passed into this
+    alternate invocation of the build.
+
+    Any default system arguments or arguments passed in via "gn args" will also
+    be passed to the alternate invocation unless explicitly overridden by
+    toolchain_args.
+
+    The toolchain_args will be ignored when the toolchain being defined is the
+    default. In this case, it's expected you want the default argument values.
+
+    See also "gn help buildargs" for an overview of these arguments.
+
+  deps
+    Dependencies of this toolchain. These dependencies will be resolved before
+    any target in the toolchain is compiled. To avoid circular dependencies
+    these must be targets defined in another toolchain.
+
+    This is expressed as a list of targets, and generally these targets will
+    always specify a toolchain:
+      deps = [ "//foo/bar:baz(//build/toolchain:bootstrap)" ]
+
+    This concept is somewhat inefficient to express in Ninja (it requires a lot
+    of duplicate of rules) so should only be used when absolutely necessary.
+```
+
+#### **Example of defining a toolchain**
+
+```
+  toolchain("32") {
+    tool("cc") {
+      command = "gcc {{source}}"
+      ...
+    }
+
+    toolchain_args = {
+      use_doom_melon = true  # Doom melon always required for 32-bit builds.
+      current_cpu = "x86"
+    }
+  }
+
+  toolchain("64") {
+    tool("cc") {
+      command = "gcc {{source}}"
+      ...
+    }
+
+    toolchain_args = {
+      # use_doom_melon is not overridden here, it will take the default.
+      current_cpu = "x64"
+    }
+  }
+```
+
+#### **Example of cross-toolchain dependencies**
+
+```
+  If a 64-bit target wants to depend on a 32-bit binary, it would specify a
+  dependency using data_deps (data deps are like deps that are only needed at
+  runtime and aren't linked, since you can't link a 32-bit and a 64-bit
+  library).
+
+    executable("my_program") {
+      ...
+      if (target_cpu == "x64") {
+        # The 64-bit build needs this 32-bit helper.
+        data_deps = [ ":helper(//toolchains:32)" ]
+      }
+    }
+
+    if (target_cpu == "x86") {
+      # Our helper library is only compiled in 32-bits.
+      shared_library("helper") {
+        ...
+      }
+    }
+```
+### <a name="write_file"></a>**write_file**: Write a file to disk.
+
+```
+  write_file(filename, data)
+
+  If data is a list, the list will be written one-item-per-line with no quoting
+  or brackets.
+
+  If the file exists and the contents are identical to that being written, the
+  file will not be updated. This will prevent unnecessary rebuilds of targets
+  that depend on this file.
+
+  One use for write_file is to write a list of inputs to an script that might
+  be too long for the command line. However, it is preferable to use response
+  files for this purpose. See "gn help response_file_contents".
+
+  TODO(brettw) we probably need an optional third argument to control list
+  formatting.
+```
+
+#### **Arguments**
+
+```
+  filename
+      Filename to write. This must be within the output directory.
+
+  data
+      The list or string to write.
+```
+## <a name="predefined_variables"></a>Built-in predefined variables
+
+### <a name="current_cpu"></a>**current_cpu**: The processor architecture of the current toolchain.
+
+```
+  The build configuration usually sets this value based on the value of
+  "host_cpu" (see "gn help host_cpu") and then threads this through the
+  toolchain definitions to ensure that it always reflects the appropriate
+  value.
+
+  This value is not used internally by GN for any purpose. It is set it to the
+  empty string ("") by default but is declared so that it can be overridden on
+  the command line if so desired.
+
+  See "gn help target_cpu" for a list of common values returned.
+```
+### <a name="current_os"></a>**current_os**: The operating system of the current toolchain.
+
+```
+  The build configuration usually sets this value based on the value of
+  "target_os" (see "gn help target_os"), and then threads this through the
+  toolchain definitions to ensure that it always reflects the appropriate
+  value.
+
+  This value is not used internally by GN for any purpose. It is set it to the
+  empty string ("") by default but is declared so that it can be overridden on
+  the command line if so desired.
+
+  See "gn help target_os" for a list of common values returned.
+```
+### <a name="current_toolchain"></a>**current_toolchain**: Label of the current toolchain.
+
+```
+  A fully-qualified label representing the current toolchain. You can use this
+  to make toolchain-related decisions in the build. See also
+  "default_toolchain".
+```
+
+#### **Example**
+
+```
+  if (current_toolchain == "//build:64_bit_toolchain") {
+    executable("output_thats_64_bit_only") {
+      ...
+```
+### <a name="default_toolchain"></a>**default_toolchain**: [string] Label of the default toolchain.
+
+```
+  A fully-qualified label representing the default toolchain, which may not
+  necessarily be the current one (see "current_toolchain").
+```
+### <a name="host_cpu"></a>**host_cpu**: The processor architecture that GN is running on.
+
+```
+  This is value is exposed so that cross-compile toolchains can access the host
+  architecture when needed.
+
+  The value should generally be considered read-only, but it can be overriden
+  in order to handle unusual cases where there might be multiple plausible
+  values for the host architecture (e.g., if you can do either 32-bit or 64-bit
+  builds). The value is not used internally by GN for any purpose.
+```
+
+#### **Some possible values**
+
+```
+  - "x64"
+  - "x86"
+```
+### <a name="host_os"></a>**host_os**: [string] The operating system that GN is running on.
+
+```
+  This value is exposed so that cross-compiles can access the host build
+  system's settings.
+
+  This value should generally be treated as read-only. It, however, is not used
+  internally by GN for any purpose.
+```
+
+#### **Some possible values**
+
+```
+  - "linux"
+  - "mac"
+  - "win"
+```
+### <a name="invoker"></a>**invoker**: [string] The invoking scope inside a template.
+
+```
+  Inside a template invocation, this variable refers to the scope of the
+  invoker of the template. Outside of template invocations, this variable is
+  undefined.
+
+  All of the variables defined inside the template invocation are accessible as
+  members of the "invoker" scope. This is the way that templates read values
+  set by the callers.
+
+  This is often used with "defined" to see if a value is set on the invoking
+  scope.
+
+  See "gn help template" for more examples.
+```
+
+#### **Example**
+
+```
+  template("my_template") {
+    print(invoker.sources)       # Prints [ "a.cc", "b.cc" ]
+    print(defined(invoker.foo))  # Prints false.
+    print(defined(invoker.bar))  # Prints true.
+  }
+
+  my_template("doom_melon") {
+    sources = [ "a.cc", "b.cc" ]
+    bar = 123
+  }
+```
+### <a name="python_path"></a>**python_path**: Absolute path of Python.
+
+```
+  Normally used in toolchain definitions if running some command requires
+  Python. You will normally not need this when invoking scripts since GN
+  automatically finds it for you.
+```
+### <a name="root_build_dir"></a>**root_build_dir**: [string] Directory where build commands are run.
+
+```
+  This is the root build output directory which will be the current directory
+  when executing all compilers and scripts.
+
+  Most often this is used with rebase_path (see "gn help rebase_path") to
+  convert arguments to be relative to a script's current directory.
+```
+### <a name="root_gen_dir"></a>**root_gen_dir**: Directory for the toolchain's generated files.
+
+```
+  Absolute path to the root of the generated output directory tree for the
+  current toolchain. An example would be "//out/Debug/gen" for the default
+  toolchain, or "//out/Debug/arm/gen" for the "arm" toolchain.
+
+  This is primarily useful for setting up include paths for generated files. If
+  you are passing this to a script, you will want to pass it through
+  rebase_path() (see "gn help rebase_path") to convert it to be relative to the
+  build directory.
+
+  See also "target_gen_dir" which is usually a better location for generated
+  files. It will be inside the root generated dir.
+```
+### <a name="root_out_dir"></a>**root_out_dir**: [string] Root directory for toolchain output files.
+
+```
+  Absolute path to the root of the output directory tree for the current
+  toolchain. It will not have a trailing slash.
+
+  For the default toolchain this will be the same as the root_build_dir. An
+  example would be "//out/Debug" for the default toolchain, or
+  "//out/Debug/arm" for the "arm" toolchain.
+
+  This is primarily useful for setting up script calls. If you are passing this
+  to a script, you will want to pass it through rebase_path() (see "gn help
+  rebase_path") to convert it to be relative to the build directory.
+
+  See also "target_out_dir" which is usually a better location for output
+  files. It will be inside the root output dir.
+```
+
+#### **Example**
+
+```
+  action("myscript") {
+    # Pass the output dir to the script.
+    args = [ "-o", rebase_path(root_out_dir, root_build_dir) ]
+  }
+```
+### <a name="target_cpu"></a>**target_cpu**: The desired cpu architecture for the build.
+
+```
+  This value should be used to indicate the desired architecture for the
+  primary objects of the build. It will match the cpu architecture of the
+  default toolchain, but not necessarily the current toolchain.
+
+  In many cases, this is the same as "host_cpu", but in the case of
+  cross-compiles, this can be set to something different. This value is
+  different from "current_cpu" in that it does not change based on the current
+  toolchain. When writing rules, "current_cpu" should be used rather than
+  "target_cpu" most of the time.
+
+  This value is not used internally by GN for any purpose, so it may be set to
+  whatever value is needed for the build. GN defaults this value to the empty
+  string ("") and the configuration files should set it to an appropriate value
+  (e.g., setting it to the value of "host_cpu") if it is not overridden on the
+  command line or in the args.gn file.
+```
+
+#### **Possible values**
+
+```
+  - "x86"
+  - "x64"
+  - "arm"
+  - "arm64"
+  - "mipsel"
+```
+### <a name="target_gen_dir"></a>**target_gen_dir**: Directory for a target's generated files.
+
+```
+  Absolute path to the target's generated file directory. This will be the
+  "root_gen_dir" followed by the relative path to the current build file. If
+  your file is in "//tools/doom_melon" then target_gen_dir would be
+  "//out/Debug/gen/tools/doom_melon". It will not have a trailing slash.
+
+  This is primarily useful for setting up include paths for generated files. If
+  you are passing this to a script, you will want to pass it through
+  rebase_path() (see "gn help rebase_path") to convert it to be relative to the
+  build directory.
+
+  See also "gn help root_gen_dir".
+```
+
+#### **Example**
+
+```
+  action("myscript") {
+    # Pass the generated output dir to the script.
+    args = [ "-o", rebase_path(target_gen_dir, root_build_dir) ]"
+  }
+```
+### <a name="target_name"></a>**target_name**: [string] The name of the current target.
+
+```
+  Inside a target or template invocation, this variable refers to the name
+  given to the target or template invocation. Outside of these, this variable
+  is undefined.
+
+  This is most often used in template definitions to name targets defined in
+  the template based on the name of the invocation. This is necessary both to
+  ensure generated targets have unique names and to generate a target with the
+  exact name of the invocation that other targets can depend on.
+
+  Be aware that this value will always reflect the innermost scope. So when
+  defining a target inside a template, target_name will refer to the target
+  rather than the template invocation. To get the name of the template
+  invocation in this case, you should save target_name to a temporary variable
+  outside of any target definitions.
+
+  See "gn help template" for more examples.
+```
+
+#### **Example**
+
+```
+  executable("doom_melon") {
+    print(target_name)    # Prints "doom_melon".
+  }
+
+  template("my_template") {
+    print(target_name)    # Prints "space_ray" when invoked below.
+
+    executable(target_name + "_impl") {
+      print(target_name)  # Prints "space_ray_impl".
+    }
+  }
+
+  my_template("space_ray") {
+  }
+```
+### <a name="target_os"></a>**target_os**: The desired operating system for the build.
+
+```
+  This value should be used to indicate the desired operating system for the
+  primary object(s) of the build. It will match the OS of the default
+  toolchain.
+
+  In many cases, this is the same as "host_os", but in the case of
+  cross-compiles, it may be different. This variable differs from "current_os"
+  in that it can be referenced from inside any toolchain and will always return
+  the initial value.
+
+  This should be set to the most specific value possible. So, "android" or
+  "chromeos" should be used instead of "linux" where applicable, even though
+  Android and ChromeOS are both Linux variants. This can mean that one needs to
+  write
+
+      if (target_os == "android" || target_os == "linux") {
+          # ...
+      }
+
+  and so forth.
+
+  This value is not used internally by GN for any purpose, so it may be set to
+  whatever value is needed for the build. GN defaults this value to the empty
+  string ("") and the configuration files should set it to an appropriate value
+  (e.g., setting it to the value of "host_os") if it is not set via the command
+  line or in the args.gn file.
+```
+
+#### **Possible values**
+
+```
+  - "android"
+  - "chromeos"
+  - "ios"
+  - "linux"
+  - "nacl"
+  - "mac"
+  - "win"
+```
+### <a name="target_out_dir"></a>**target_out_dir**: [string] Directory for target output files.
+
+```
+  Absolute path to the target's generated file directory. If your current
+  target is in "//tools/doom_melon" then this value might be
+  "//out/Debug/obj/tools/doom_melon". It will not have a trailing slash.
+
+  This is primarily useful for setting up arguments for calling scripts. If you
+  are passing this to a script, you will want to pass it through rebase_path()
+  (see "gn help rebase_path") to convert it to be relative to the build
+  directory.
+
+  See also "gn help root_out_dir".
+```
+
+#### **Example**
+
+```
+  action("myscript") {
+    # Pass the output dir to the script.
+    args = [ "-o", rebase_path(target_out_dir, root_build_dir) ]"
+
+  }
+```
+## <a name="target_variables"></a>Variables you set in targets
+
+### <a name="all_dependent_configs"></a>**all_dependent_configs**: Configs to be forced on dependents.
+
+```
+  A list of config labels.
+
+  All targets depending on this one, and recursively, all targets depending on
+  those, will have the configs listed in this variable added to them. These
+  configs will also apply to the current target.
+
+  This addition happens in a second phase once a target and all of its
+  dependencies have been resolved. Therefore, a target will not see these
+  force-added configs in their "configs" variable while the script is running,
+  and they can not be removed. As a result, this capability should generally
+  only be used to add defines and include directories necessary to compile a
+  target's headers.
+
+  See also "public_configs".
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="allow_circular_includes_from"></a>**allow_circular_includes_from**: Permit includes from deps.
+
+```
+  A list of target labels. Must be a subset of the target's "deps". These
+  targets will be permitted to include headers from the current target despite
+  the dependency going in the opposite direction.
+
+  When you use this, both targets must be included in a final binary for it to
+  link. To keep linker errors from happening, it is good practice to have all
+  external dependencies depend only on one of the two targets, and to set the
+  visibility on the other to enforce this. Thus the targets will always be
+  linked together in any output.
+```
+
+#### **Details**
+
+```
+  Normally, for a file in target A to include a file from target B, A must list
+  B as a dependency. This invariant is enforced by the "gn check" command (and
+  the --check flag to "gn gen" -- see "gn help check").
+
+  Sometimes, two targets might be the same unit for linking purposes (two
+  source sets or static libraries that would always be linked together in a
+  final executable or shared library) and they each include headers from the
+  other: you want A to be able to include B's headers, and B to include A's
+  headers. This is not an ideal situation but is sometimes unavoidable.
+
+  This list, if specified, lists which of the dependencies of the current
+  target can include header files from the current target. That is, if A
+  depends on B, B can only include headers from A if it is in A's
+  allow_circular_includes_from list. Normally includes must follow the
+  direction of dependencies, this flag allows them to go in the opposite
+  direction.
+```
+
+#### **Danger**
+
+```
+  In the above example, A's headers are likely to include headers from A's
+  dependencies. Those dependencies may have public_configs that apply flags,
+  defines, and include paths that make those headers work properly.
+
+  With allow_circular_includes_from, B can include A's headers, and
+  transitively from A's dependencies, without having the dependencies that
+  would bring in the public_configs those headers need. The result may be
+  errors or inconsistent builds.
+
+  So when you use allow_circular_includes_from, make sure that any compiler
+  settings, flags, and include directories are the same between both targets
+  (consider putting such things in a shared config they can both reference).
+  Make sure the dependencies are also the same (you might consider a group to
+  collect such dependencies they both depend on).
+```
+
+#### **Example**
+
+```
+  source_set("a") {
+    deps = [ ":b", ":a_b_shared_deps" ]
+    allow_circular_includes_from = [ ":b" ]
+    ...
+  }
+
+  source_set("b") {
+    deps = [ ":a_b_shared_deps" ]
+    # Sources here can include headers from a despite lack of deps.
+    ...
+  }
+
+  group("a_b_shared_deps") {
+    public_deps = [ ":c" ]
+  }
+```
+### <a name="arflags"></a>**arflags**: Arguments passed to static_library archiver.
+
+```
+  A list of flags passed to the archive/lib command that creates static
+  libraries.
+
+  arflags are NOT pushed to dependents, so applying arflags to source sets or
+  any other target type will be a no-op. As with ldflags, you could put the
+  arflags in a config and set that as a public or "all dependent" config, but
+  that will likely not be what you want. If you have a chain of static
+  libraries dependent on each other, this can cause the flags to propagate up
+  to other static libraries. Due to the nature of how arflags are typically
+  used, you will normally want to apply them directly on static_library targets
+  themselves.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="args"></a>**args**: Arguments passed to an action.
+
+```
+  For action and action_foreach targets, args is the list of arguments to pass
+  to the script. Typically you would use source expansion (see "gn help
+  source_expansion") to insert the source file names.
+
+  See also "gn help action" and "gn help action_foreach".
+```
+### <a name="asmflags"></a>**asmflags**: Flags passed to the assembler.
+
+```
+  A list of strings.
+
+  "asmflags" are passed to any invocation of a tool that takes an .asm or .S
+  file as input.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="assert_no_deps"></a>**assert_no_deps**: Ensure no deps on these targets.
+
+```
+  A list of label patterns.
+
+  This list is a list of patterns that must not match any of the transitive
+  dependencies of the target. These include all public, private, and data
+  dependencies, and cross shared library boundaries. This allows you to express
+  that undesirable code isn't accidentally added to downstream dependencies in
+  a way that might otherwise be difficult to notice.
+
+  Checking does not cross executable boundaries. If a target depends on an
+  executable, it's assumed that the executable is a tool that is producing part
+  of the build rather than something that is linked and distributed. This
+  allows assert_no_deps to express what is distributed in the final target
+  rather than depend on the internal build steps (which may include
+  non-distributable code).
+
+  See "gn help label_pattern" for the format of the entries in the list. These
+  patterns allow blacklisting individual targets or whole directory
+  hierarchies.
+
+  Sometimes it is desirable to enforce that many targets have no dependencies
+  on a target or set of targets. One efficient way to express this is to create
+  a group with the assert_no_deps rule on it, and make that group depend on all
+  targets you want to apply that assertion to.
+```
+
+#### **Example**
+
+```
+  executable("doom_melon") {
+    deps = [ "//foo:bar" ]
+    ...
+    assert_no_deps = [
+      "//evil/*",  # Don't link any code from the evil directory.
+      "//foo:test_support",  # This target is also disallowed.
+    ]
+  }
+```
+### <a name="bundle_contents_dir"></a>**bundle_contents_dir**: Expansion of {{bundle_contents_dir}} in
+```
+                             create_bundle.
+
+  A string corresponding to a path in $root_build_dir.
+
+  This string is used by the "create_bundle" target to expand the
+  {{bundle_contents_dir}} of the "bundle_data" target it depends on. This must
+  correspond to a path under "bundle_root_dir".
+
+  See "gn help bundle_root_dir" for examples.
+```
+### <a name="bundle_deps_filter"></a>**bundle_deps_filter**: [label list] A list of labels that are filtered out.
+
+```
+  A list of target labels.
+
+  This list contains target label patterns that should be filtered out when
+  creating the bundle. Any target matching one of those label will be removed
+  from the dependencies of the create_bundle target.
+
+  This is mostly useful when creating application extension bundle as the
+  application extension has access to runtime resources from the application
+  bundle and thus do not require a second copy.
+
+  See "gn help create_bundle" for more information.
+```
+
+#### **Example**
+
+```
+  create_bundle("today_extension") {
+    deps = [
+      "//base"
+    ]
+    bundle_root_dir = "$root_out_dir/today_extension.appex"
+    bundle_deps_filter = [
+      # The extension uses //base but does not use any function calling into
+      # third_party/icu and thus does not need the icudtl.dat file.
+      "//third_party/icu:icudata",
+    ]
+  }
+```
+### <a name="bundle_executable_dir"></a>**bundle_executable_dir**: Expansion of {{bundle_executable_dir}} in
+```
+                              create_bundle.
+
+  A string corresponding to a path in $root_build_dir.
+
+  This string is used by the "create_bundle" target to expand the
+  {{bundle_executable_dir}} of the "bundle_data" target it depends on. This
+  must correspond to a path under "bundle_root_dir".
+
+  See "gn help bundle_root_dir" for examples.
+```
+### <a name="bundle_plugins_dir"></a>**bundle_plugins_dir**: Expansion of {{bundle_plugins_dir}} in create_bundle.
+
+```
+  A string corresponding to a path in $root_build_dir.
+
+  This string is used by the "create_bundle" target to expand the
+  {{bundle_plugins_dir}} of the "bundle_data" target it depends on. This must
+  correspond to a path under "bundle_root_dir".
+
+  See "gn help bundle_root_dir" for examples.
+```
+### <a name="bundle_resources_dir"></a>**bundle_resources_dir**: Expansion of {{bundle_resources_dir}} in
+```
+                             create_bundle.
+
+  A string corresponding to a path in $root_build_dir.
+
+  This string is used by the "create_bundle" target to expand the
+  {{bundle_resources_dir}} of the "bundle_data" target it depends on. This must
+  correspond to a path under "bundle_root_dir".
+
+  See "gn help bundle_root_dir" for examples.
+```
+### <a name="bundle_root_dir"></a>**bundle_root_dir**: Expansion of {{bundle_root_dir}} in create_bundle.
+
+```
+  A string corresponding to a path in root_build_dir.
+
+  This string is used by the "create_bundle" target to expand the
+  {{bundle_root_dir}} of the "bundle_data" target it depends on. This must
+  correspond to a path under root_build_dir.
+```
+
+#### **Example**
+
+```
+  bundle_data("info_plist") {
+    sources = [ "Info.plist" ]
+    outputs = [ "{{bundle_contents_dir}}/Info.plist" ]
+  }
+
+  create_bundle("doom_melon.app") {
+    deps = [ ":info_plist" ]
+    bundle_root_dir = "${root_build_dir}/doom_melon.app"
+    bundle_contents_dir = "${bundle_root_dir}/Contents"
+    bundle_resources_dir = "${bundle_contents_dir}/Resources"
+    bundle_executable_dir = "${bundle_contents_dir}/MacOS"
+    bundle_plugins_dir = "${bundle_contents_dir}/PlugIns"
+  }
+```
+### <a name="cflags*"></a>**cflags***: Flags passed to the C compiler.
+
+```
+  A list of strings.
+
+  "cflags" are passed to all invocations of the C, C++, Objective C, and
+  Objective C++ compilers.
+
+  To target one of these variants individually, use "cflags_c", "cflags_cc",
+  "cflags_objc", and "cflags_objcc", respectively. These variant-specific
+  versions of cflags* will be appended on the compiler command line after
+  "cflags".
+
+  See also "asmflags" for flags for assembly-language files.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="cflags*"></a>**cflags***: Flags passed to the C compiler.
+
+```
+  A list of strings.
+
+  "cflags" are passed to all invocations of the C, C++, Objective C, and
+  Objective C++ compilers.
+
+  To target one of these variants individually, use "cflags_c", "cflags_cc",
+  "cflags_objc", and "cflags_objcc", respectively. These variant-specific
+  versions of cflags* will be appended on the compiler command line after
+  "cflags".
+
+  See also "asmflags" for flags for assembly-language files.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="cflags*"></a>**cflags***: Flags passed to the C compiler.
+
+```
+  A list of strings.
+
+  "cflags" are passed to all invocations of the C, C++, Objective C, and
+  Objective C++ compilers.
+
+  To target one of these variants individually, use "cflags_c", "cflags_cc",
+  "cflags_objc", and "cflags_objcc", respectively. These variant-specific
+  versions of cflags* will be appended on the compiler command line after
+  "cflags".
+
+  See also "asmflags" for flags for assembly-language files.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="cflags*"></a>**cflags***: Flags passed to the C compiler.
+
+```
+  A list of strings.
+
+  "cflags" are passed to all invocations of the C, C++, Objective C, and
+  Objective C++ compilers.
+
+  To target one of these variants individually, use "cflags_c", "cflags_cc",
+  "cflags_objc", and "cflags_objcc", respectively. These variant-specific
+  versions of cflags* will be appended on the compiler command line after
+  "cflags".
+
+  See also "asmflags" for flags for assembly-language files.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="cflags*"></a>**cflags***: Flags passed to the C compiler.
+
+```
+  A list of strings.
+
+  "cflags" are passed to all invocations of the C, C++, Objective C, and
+  Objective C++ compilers.
+
+  To target one of these variants individually, use "cflags_c", "cflags_cc",
+  "cflags_objc", and "cflags_objcc", respectively. These variant-specific
+  versions of cflags* will be appended on the compiler command line after
+  "cflags".
+
+  See also "asmflags" for flags for assembly-language files.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="check_includes"></a>**check_includes**: [boolean] Controls whether a target's files are checked.
+
+```
+  When true (the default), the "gn check" command (as well as "gn gen" with the
+  --check flag) will check this target's sources and headers for proper
+  dependencies.
+
+  When false, the files in this target will be skipped by default. This does
+  not affect other targets that depend on the current target, it just skips
+  checking the includes of the current target's files.
+
+  If there are a few conditionally included headers that trip up checking, you
+  can exclude headers individually by annotating them with "nogncheck" (see "gn
+  help nogncheck").
+
+  The topic "gn help check" has general information on how checking works and
+  advice on how to pass a check in problematic cases.
+```
+
+#### **Example**
+
+```
+  source_set("busted_includes") {
+    # This target's includes are messed up, exclude it from checking.
+    check_includes = false
+    ...
+  }
+```
+### <a name="code_signing_args"></a>**code_signing_args**: [string list] Arguments passed to code signing script.
+
+```
+  For create_bundle targets, code_signing_args is the list of arguments to pass
+  to the code signing script. Typically you would use source expansion (see "gn
+  help source_expansion") to insert the source file names.
+
+  See also "gn help create_bundle".
+```
+### <a name="code_signing_outputs"></a>**code_signing_outputs**: [file list] Output files for code signing step.
+
+```
+  Outputs from the code signing step of a create_bundle target. Must refer to
+  files in the build directory.
+
+  See also "gn help create_bundle".
+```
+### <a name="code_signing_script"></a>**code_signing_script**: [file name] Script for code signing."
+
+```
+  An absolute or buildfile-relative file name of a Python script to run for a
+  create_bundle target to perform code signing step.
+
+  See also "gn help create_bundle".
+```
+### <a name="code_signing_sources"></a>**code_signing_sources**: [file list] Sources for code signing step.
+
+```
+  A list of files used as input for code signing script step of a create_bundle
+  target. Non-absolute paths will be resolved relative to the current build
+  file.
+
+  See also "gn help create_bundle".
+```
+### <a name="complete_static_lib"></a>**complete_static_lib**: [boolean] Links all deps into a static library.
+
+```
+  A static library normally doesn't include code from dependencies, but instead
+  forwards the static libraries and source sets in its deps up the dependency
+  chain until a linkable target (an executable or shared library) is reached.
+  The final linkable target only links each static library once, even if it
+  appears more than once in its dependency graph.
+
+  In some cases the static library might be the final desired output. For
+  example, you may be producing a static library for distribution to third
+  parties. In this case, the static library should include code for all
+  dependencies in one complete package. However, complete static libraries
+  themselves are never linked into other complete static libraries. All
+  complete static libraries are for distribution and linking them in would
+  cause code duplication in this case. If the static library is not for
+  distribution, it should not be complete.
+
+  GN treats non-complete static libraries as source sets when they are linked
+  into complete static libraries. This is done because some tools like AR do
+  not handle dependent static libraries properly. This makes it easier to write
+  "alink" rules.
+
+  In rare cases it makes sense to list a header in more than one target if it
+  could be considered conceptually a member of both. libraries.
+```
+
+#### **Example**
+
+```
+  static_library("foo") {
+    complete_static_lib = true
+    deps = [ "bar" ]
+  }
+```
+### <a name="configs"></a>**configs**: Configs applying to this target or config.
+
+```
+  A list of config labels.
+```
+
+#### **Configs on a target**
+
+```
+  When used on a target, the include_dirs, defines, etc. in each config are
+  appended in the order they appear to the compile command for each file in the
+  target. They will appear after the include_dirs, defines, etc. that the
+  target sets directly.
+
+  Since configs apply after the values set on a target, directly setting a
+  compiler flag will prepend it to the command line. If you want to append a
+  flag instead, you can put that flag in a one-off config and append that
+  config to the target's configs list.
+
+  The build configuration script will generally set up the default configs
+  applying to a given target type (see "set_defaults"). When a target is being
+  defined, it can add to or remove from this list.
+```
+
+#### **Configs on a config**
+
+```
+  It is possible to create composite configs by specifying configs on a config.
+  One might do this to forward values, or to factor out blocks of settings from
+  very large configs into more manageable named chunks.
+
+  In this case, the composite config is expanded to be the concatenation of its
+  own values, and in order, the values from its sub-configs *before* anything
+  else happens. This has some ramifications:
+
+   - A target has no visibility into a config's sub-configs. Target code only
+     sees the name of the composite config. It can't remove sub-configs or opt
+     in to only parts of it. The composite config may not even be defined
+     before the target is.
+
+   - You can get duplication of values if a config is listed twice, say, on a
+     target and in a sub-config that also applies. In other cases, the configs
+     applying to a target are de-duped. It's expected that if a config is
+     listed as a sub-config that it is only used in that context. (Note that
+     it's possible to fix this and de-dupe, but it's not normally relevant and
+     complicates the implementation.)
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+
+#### **Example**
+
+```
+  # Configs on a target.
+  source_set("foo") {
+    # Don't use the default RTTI config that BUILDCONFIG applied to us.
+    configs -= [ "//build:no_rtti" ]
+
+    # Add some of our own settings.
+    configs += [ ":mysettings" ]
+  }
+
+  # Create a default_optimization config that forwards to one of a set of more
+  # specialized configs depending on build flags. This pattern is useful
+  # because it allows a target to opt in to either a default set, or a more
+  # specific set, while avoid duplicating the settings in two places.
+  config("super_optimization") {
+    cflags = [ ... ]
+  }
+  config("default_optimization") {
+    if (optimize_everything) {
+      configs = [ ":super_optimization" ]
+    } else {
+      configs = [ ":no_optimization" ]
+    }
+  }
+```
+### <a name="data"></a>**data**: Runtime data file dependencies.
+
+```
+  Lists files or directories required to run the given target. These are
+  typically data files or directories of data files. The paths are interpreted
+  as being relative to the current build file. Since these are runtime
+  dependencies, they do not affect which targets are built or when. To declare
+  input files to a script, use "inputs".
+
+  Appearing in the "data" section does not imply any special handling such as
+  copying them to the output directory. This is just used for declaring runtime
+  dependencies. Runtime dependencies can be queried using the "runtime_deps"
+  category of "gn desc" or written during build generation via
+  "--runtime-deps-list-file".
+
+  GN doesn't require data files to exist at build-time. So actions that produce
+  files that are in turn runtime dependencies can list those generated files
+  both in the "outputs" list as well as the "data" list.
+
+  By convention, directories are listed with a trailing slash:
+    data = [ "test/data/" ]
+  However, no verification is done on these so GN doesn't enforce this. The
+  paths are just rebased and passed along when requested.
+
+  Note: On iOS and macOS, create_bundle targets will not be recursed into when
+  gathering data. See "gn help create_bundle" for details.
+
+  See "gn help runtime_deps" for how these are used.
+```
+### <a name="data_deps"></a>**data_deps**: Non-linked dependencies.
+
+```
+  A list of target labels.
+
+  Specifies dependencies of a target that are not actually linked into the
+  current target. Such dependencies will be built and will be available at
+  runtime.
+
+  This is normally used for things like plugins or helper programs that a
+  target needs at runtime.
+
+  Note: On iOS and macOS, create_bundle targets will not be recursed into when
+  gathering data_deps. See "gn help create_bundle" for details.
+
+  See also "gn help deps" and "gn help data".
+```
+
+#### **Example**
+
+```
+  executable("foo") {
+    deps = [ "//base" ]
+    data_deps = [ "//plugins:my_runtime_plugin" ]
+  }
+```
+### <a name="defines"></a>**defines**: C preprocessor defines.
+
+```
+  A list of strings
+
+  These strings will be passed to the C/C++ compiler as #defines. The strings
+  may or may not include an "=" to assign a value.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+
+#### **Example**
+
+```
+  defines = [ "AWESOME_FEATURE", "LOG_LEVEL=3" ]
+```
+### <a name="depfile"></a>**depfile**: [string] File name for input dependencies for actions.
+
+```
+  If nonempty, this string specifies that the current action or action_foreach
+  target will generate the given ".d" file containing the dependencies of the
+  input. Empty or unset means that the script doesn't generate the files.
+
+  A depfile should be used only when a target depends on files that are not
+  already specified by a target's inputs and sources. Likewise, depfiles should
+  specify only those dependencies not already included in sources or inputs.
+
+  The .d file should go in the target output directory. If you have more than
+  one source file that the script is being run over, you can use the output
+  file expansions described in "gn help action_foreach" to name the .d file
+  according to the input."
+
+  The format is that of a Makefile and all paths must be relative to the root
+  build directory. Only one output may be listed and it must match the first
+  output of the action.
+
+  Although depfiles are created by an action, they should not be listed in the
+  action's "outputs" unless another target will use the file as an input.
+```
+
+#### **Example**
+
+```
+  action_foreach("myscript_target") {
+    script = "myscript.py"
+    sources = [ ... ]
+
+    # Locate the depfile in the output directory named like the
+    # inputs but with a ".d" appended.
+    depfile = "$relative_target_output_dir/{{source_name}}.d"
+
+    # Say our script uses "-o <d file>" to indicate the depfile.
+    args = [ "{{source}}", "-o", depfile ]
+  }
+```
+### <a name="deps"></a>**deps**: Private linked dependencies.
+
+```
+  A list of target labels.
+
+  Specifies private dependencies of a target. Private dependencies are
+  propagated up the dependency tree and linked to dependent targets, but do not
+  grant the ability to include headers from the dependency. Public configs are
+  not forwarded.
+```
+
+#### **Details of dependency propagation**
+
+```
+  Source sets, shared libraries, and non-complete static libraries will be
+  propagated up the dependency tree across groups, non-complete static
+  libraries and source sets.
+
+  Executables, shared libraries, and complete static libraries will link all
+  propagated targets and stop propagation. Actions and copy steps also stop
+  propagation, allowing them to take a library as an input but not force
+  dependents to link to it.
+
+  Propagation of all_dependent_configs and public_configs happens independently
+  of target type. all_dependent_configs are always propagated across all types
+  of targets, and public_configs are always propagated across public deps of
+  all types of targets.
+
+  Data dependencies are propagated differently. See "gn help data_deps" and
+  "gn help runtime_deps".
+
+  See also "public_deps".
+```
+### <a name="friend"></a>**friend**: Allow targets to include private headers.
+
+```
+  A list of label patterns (see "gn help label_pattern") that allow dependent
+  targets to include private headers. Applies to all binary targets.
+
+  Normally if a target lists headers in the "public" list (see "gn help
+  public"), other headers are implicitly marked as private. Private headers
+  can not be included by other targets, even with a public dependency path.
+  The "gn check" function performs this validation.
+
+  A friend declaration allows one or more targets to include private headers.
+  This is useful for things like unit tests that are closely associated with a
+  target and require internal knowledge without opening up all headers to be
+  included by all dependents.
+
+  A friend target does not allow that target to include headers when no
+  dependency exists. A public dependency path must still exist between two
+  targets to include any headers from a destination target. The friend
+  annotation merely allows the use of headers that would otherwise be
+  prohibited because they are private.
+
+  The friend annotation is matched only against the target containing the file
+  with the include directive. Friend annotations are not propagated across
+  public or private dependencies. Friend annotations do not affect visibility.
+```
+
+#### **Example**
+
+```
+  static_library("lib") {
+    # This target can include our private headers.
+    friend = [ ":unit_tests" ]
+
+    public = [
+      "public_api.h",  # Normal public API for dependent targets.
+    ]
+
+    # Private API and sources.
+    sources = [
+      "a_source_file.cc",
+
+      # Normal targets that depend on this one won't be able to include this
+      # because this target defines a list of "public" headers. Without the
+      # "public" list, all headers are implicitly public.
+      "private_api.h",
+    ]
+  }
+
+  executable("unit_tests") {
+    sources = [
+      # This can include "private_api.h" from the :lib target because it
+      # depends on that target and because of the friend annotation.
+      "my_test.cc",
+    ]
+
+    deps = [
+      ":lib",  # Required for the include to be allowed.
+    ]
+  }
+```
+### <a name="include_dirs"></a>**include_dirs**: Additional include directories.
+
+```
+  A list of source directories.
+
+  The directories in this list will be added to the include path for the files
+  in the affected target.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+
+#### **Example**
+
+```
+  include_dirs = [ "src/include", "//third_party/foo" ]
+```
+### <a name="inputs"></a>**inputs**: Additional compile-time dependencies.
+
+```
+  Inputs are compile-time dependencies of the current target. This means that
+  all inputs must be available before compiling any of the sources or executing
+  any actions.
+
+  Inputs are typically only used for action and action_foreach targets.
+```
+
+#### **Inputs for actions**
+
+```
+  For action and action_foreach targets, inputs should be the inputs to script
+  that don't vary. These should be all .py files that the script uses via
+  imports (the main script itself will be an implicit dependency of the action
+  so need not be listed).
+
+  For action targets, inputs and sources are treated the same, but from a style
+  perspective, it's recommended to follow the same rule as action_foreach and
+  put helper files in the inputs, and the data used by the script (if any) in
+  sources.
+
+  Note that another way to declare input dependencies from an action is to have
+  the action write a depfile (see "gn help depfile"). This allows the script to
+  dynamically write input dependencies, that might not be known until actually
+  executing the script. This is more efficient than doing processing while
+  running GN to determine the inputs, and is easier to keep in-sync than
+  hardcoding the list.
+```
+
+#### **Script input gotchas**
+
+```
+  It may be tempting to write a script that enumerates all files in a directory
+  as inputs. Don't do this! Even if you specify all the files in the inputs or
+  sources in the GN target (or worse, enumerate the files in an exec_script
+  call when running GN, which will be slow), the dependencies will be broken.
+
+  The problem happens if a file is ever removed because the inputs are not
+  listed on the command line to the script. Because the script hasn't changed
+  and all inputs are up to date, the script will not re-run and you will get a
+  stale build. Instead, either list all inputs on the command line to the
+  script, or if there are many, create a separate list file that the script
+  reads. As long as this file is listed in the inputs, the build will detect
+  when it has changed in any way and the action will re-run.
+```
+
+#### **Inputs for binary targets**
+
+```
+  Any input dependencies will be resolved before compiling any sources.
+  Normally, all actions that a target depends on will be run before any files
+  in a target are compiled. So if you depend on generated headers, you do not
+  typically need to list them in the inputs section.
+
+  Inputs for binary targets will be treated as implicit dependencies, meaning
+  that changes in any of the inputs will force all sources in the target to be
+  recompiled. If an input only applies to a subset of source files, you may
+  want to split those into a separate target to avoid unnecessary recompiles.
+```
+
+#### **Example**
+
+```
+  action("myscript") {
+    script = "domything.py"
+    inputs = [ "input.data" ]
+  }
+```
+### <a name="ldflags"></a>**ldflags**: Flags passed to the linker.
+
+```
+  A list of strings.
+
+  These flags are passed on the command-line to the linker and generally
+  specify various linking options. Most targets will not need these and will
+  use "libs" and "lib_dirs" instead.
+
+  ldflags are NOT pushed to dependents, so applying ldflags to source sets or
+  static libraries will be a no-op. If you want to apply ldflags to dependent
+  targets, put them in a config and set it in the all_dependent_configs or
+  public_configs.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="lib_dirs"></a>**lib_dirs**: Additional library directories.
+
+```
+  A list of directories.
+
+  Specifies additional directories passed to the linker for searching for the
+  required libraries. If an item is not an absolute path, it will be treated as
+  being relative to the current build file.
+
+  libs and lib_dirs work differently than other flags in two respects.
+  First, then are inherited across static library boundaries until a
+  shared library or executable target is reached. Second, they are
+  uniquified so each one is only passed once (the first instance of it
+  will be the one used).
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+
+  For "libs" and "lib_dirs" only, the values propagated from
+  dependencies (as described above) are applied last assuming they
+  are not already in the list.
+```
+
+#### **Example**
+
+```
+  lib_dirs = [ "/usr/lib/foo", "lib/doom_melon" ]
+```
+### <a name="libs"></a>**libs**: Additional libraries to link.
+
+```
+  A list of library names or library paths.
+
+  These libraries will be linked into the final binary (executable or shared
+  library) containing the current target.
+
+  libs and lib_dirs work differently than other flags in two respects.
+  First, then are inherited across static library boundaries until a
+  shared library or executable target is reached. Second, they are
+  uniquified so each one is only passed once (the first instance of it
+  will be the one used).
+```
+
+#### **Types of libs**
+
+```
+  There are several different things that can be expressed in libs:
+
+  File paths
+      Values containing '/' will be treated as references to files in the
+      checkout. They will be rebased to be relative to the build directory and
+      specified in the "libs" for linker tools. This facility should be used
+      for libraries that are checked in to the version control. For libraries
+      that are generated by the build, use normal GN deps to link them.
+
+  System libraries
+      Values not containing '/' will be treated as system library names. These
+      will be passed unmodified to the linker and prefixed with the
+      "lib_switch" attribute of the linker tool. Generally you would set the
+      "lib_dirs" so the given library is found. Your BUILD.gn file should not
+      specify the switch (like "-l"): this will be encoded in the "lib_switch"
+      of the tool.
+
+  Apple frameworks
+      System libraries ending in ".framework" will be special-cased: the switch
+      "-framework" will be prepended instead of the lib_switch, and the
+      ".framework" suffix will be trimmed. This is to support the way Mac links
+      framework dependencies.
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+
+  For "libs" and "lib_dirs" only, the values propagated from
+  dependencies (as described above) are applied last assuming they
+  are not already in the list.
+```
+
+#### **Examples**
+
+```
+  On Windows:
+    libs = [ "ctl3d.lib" ]
+
+  On Linux:
+    libs = [ "ld" ]
+```
+### <a name="output_dir"></a>**output_dir**: [directory] Directory to put output file in.
+
+```
+  For library and executable targets, overrides the directory for the final
+  output. This must be in the root_build_dir or a child thereof.
+
+  This should generally be in the root_out_dir or a subdirectory thereof (the
+  root_out_dir will be the same as the root_build_dir for the default
+  toolchain, and will be a subdirectory for other toolchains). Not putting the
+  output in a subdirectory of root_out_dir can result in collisions between
+  different toolchains, so you will need to take steps to ensure that your
+  target is only present in one toolchain.
+
+  Normally the toolchain specifies the output directory for libraries and
+  executables (see "gn help tool"). You will have to consult that for the
+  default location. The default location will be used if output_dir is
+  undefined or empty.
+```
+
+#### **Example**
+
+```
+  shared_library("doom_melon") {
+    output_dir = "$root_out_dir/plugin_libs"
+    ...
+  }
+```
+### <a name="output_extension"></a>**output_extension**: Value to use for the output's file extension.
+
+```
+  Normally the file extension for a target is based on the target type and the
+  operating system, but in rare cases you will need to override the name (for
+  example to use "libfreetype.so.6" instead of libfreetype.so on Linux).
+
+  This value should not include a leading dot. If undefined, the default
+  specified on the tool will be used. If set to the empty string, no output
+  extension will be used.
+
+  The output_extension will be used to set the "{{output_extension}}" expansion
+  which the linker tool will generally use to specify the output file name. See
+  "gn help tool".
+```
+
+#### **Example**
+
+```
+  shared_library("freetype") {
+    if (is_linux) {
+      # Call the output "libfreetype.so.6"
+      output_extension = "so.6"
+    }
+    ...
+  }
+
+  # On Windows, generate a "mysettings.cpl" control panel applet. Control panel
+  # applets are actually special shared libraries.
+  if (is_win) {
+    shared_library("mysettings") {
+      output_extension = "cpl"
+      ...
+    }
+  }
+```
+### <a name="output_name"></a>**output_name**: Define a name for the output file other than the default.
+
+```
+  Normally the output name of a target will be based on the target name, so the
+  target "//foo/bar:bar_unittests" will generate an output file such as
+  "bar_unittests.exe" (using Windows as an example).
+
+  Sometimes you will want an alternate name to avoid collisions or if the
+  internal name isn't appropriate for public distribution.
+
+  The output name should have no extension or prefixes, these will be added
+  using the default system rules. For example, on Linux an output name of "foo"
+  will produce a shared library "libfoo.so". There is no way to override the
+  output prefix of a linker tool on a per- target basis. If you need more
+  flexibility, create a copy target to produce the file you want.
+
+  This variable is valid for all binary output target types.
+```
+
+#### **Example**
+
+```
+  static_library("doom_melon") {
+    output_name = "fluffy_bunny"
+  }
+```
+### <a name="output_prefix_override"></a>**output_prefix_override**: Don't use prefix for output name.
+
+```
+  A boolean that overrides the output prefix for a target. Defaults to false.
+
+  Some systems use prefixes for the names of the final target output file. The
+  normal example is "libfoo.so" on Linux for a target named "foo".
+
+  The output prefix for a given target type is specified on the linker tool
+  (see "gn help tool"). Sometimes this prefix is undesired.
+
+  See also "gn help output_extension".
+```
+
+#### **Example**
+
+```
+  shared_library("doom_melon") {
+    # Normally this will produce "libdoom_melon.so" on Linux. Setting this flag
+    # will produce "doom_melon.so".
+    output_prefix_override = true
+    ...
+  }
+```
+### <a name="outputs"></a>**outputs**: Output files for actions and copy targets.
+
+```
+  Outputs is valid for "copy", "action", and "action_foreach" target types and
+  indicates the resulting files. Outputs must always refer to files in the
+  build directory.
+
+  copy
+    Copy targets should have exactly one entry in the outputs list. If there is
+    exactly one source, this can be a literal file name or a source expansion.
+    If there is more than one source, this must contain a source expansion to
+    map a single input name to a single output name. See "gn help copy".
+
+  action_foreach
+    Action_foreach targets must always use source expansions to map input files
+    to output files. There can be more than one output, which means that each
+    invocation of the script will produce a set of files (presumably based on
+    the name of the input file). See "gn help action_foreach".
+
+  action
+    Action targets (excluding action_foreach) must list literal output file(s)
+    with no source expansions. See "gn help action".
+```
+### <a name="partial_info_plist"></a>**partial_info_plist**: [filename] Path plist from asset catalog compiler.
+
+```
+  Valid for create_bundle target, corresponds to the path for the partial
+  Info.plist created by the asset catalog compiler that needs to be merged
+  with the application Info.plist (usually done by the code signing script).
+
+  The file will be generated regardless of whether the asset compiler has
+  been invoked or not. See "gn help create_bundle".
+```
+### <a name="pool"></a>**pool**: Label of the pool used by the action.
+
+```
+  A fully-qualified label representing the pool that will be used for the
+  action. Pools are defined using the pool() {...} declaration.
+```
+
+#### **Example**
+
+```
+  action("action") {
+    pool = "//build:custom_pool"
+    ...
+  }
+```
+### <a name="precompiled_header"></a>**precompiled_header**: [string] Header file to precompile.
+
+```
+  Precompiled headers will be used when a target specifies this value, or a
+  config applying to this target specifies this value. In addition, the tool
+  corresponding to the source files must also specify precompiled headers (see
+  "gn help tool"). The tool will also specify what type of precompiled headers
+  to use, by setting precompiled_header_type to either "gcc" or "msvc".
+
+  The precompiled header/source variables can be specified on a target or a
+  config, but must be the same for all configs applying to a given target since
+  a target can only have one precompiled header.
+
+  If you use both C and C++ sources, the precompiled header and source file
+  will be compiled once per language. You will want to make sure to wrap C++
+  includes in __cplusplus #ifdefs so the file will compile in C mode.
+```
+
+#### **GCC precompiled headers**
+
+```
+  When using GCC-style precompiled headers, "precompiled_source" contains the
+  path of a .h file that is precompiled and then included by all source files
+  in targets that set "precompiled_source".
+
+  The value of "precompiled_header" is not used with GCC-style precompiled
+  headers.
+```
+
+#### **MSVC precompiled headers**
+
+```
+  When using MSVC-style precompiled headers, the "precompiled_header" value is
+  a string corresponding to the header. This is NOT a path to a file that GN
+  recognises, but rather the exact string that appears in quotes after
+  an #include line in source code. The compiler will match this string against
+  includes or forced includes (/FI).
+
+  MSVC also requires a source file to compile the header with. This must be
+  specified by the "precompiled_source" value. In contrast to the header value,
+  this IS a GN-style file name, and tells GN which source file to compile to
+  make the .pch file used for subsequent compiles.
+
+  For example, if the toolchain specifies MSVC headers:
+
+    toolchain("vc_x64") {
+      ...
+      tool("cxx") {
+        precompiled_header_type = "msvc"
+        ...
+
+  You might make a config like this:
+
+    config("use_precompiled_headers") {
+      precompiled_header = "build/precompile.h"
+      precompiled_source = "//build/precompile.cc"
+
+      # Either your source files should #include "build/precompile.h"
+      # first, or you can do this to force-include the header.
+      cflags = [ "/FI$precompiled_header" ]
+    }
+
+  And then define a target that uses the config:
+
+    executable("doom_melon") {
+      configs += [ ":use_precompiled_headers" ]
+      ...
+```
+### <a name="precompiled_header_type"></a>**precompiled_header_type**: [string] "gcc" or "msvc".
+
+```
+  See "gn help precompiled_header".
+```
+### <a name="precompiled_source"></a>**precompiled_source**: [file name] Source file to precompile.
+
+```
+  The source file that goes along with the precompiled_header when using
+  "msvc"-style precompiled headers. It will be implicitly added to the sources
+  of the target. See "gn help precompiled_header".
+```
+### <a name="product_type"></a>**product_type**: Product type for Xcode projects.
+
+```
+  Correspond to the type of the product of a create_bundle target. Only
+  meaningful to Xcode (used as part of the Xcode project generation).
+
+  When generating Xcode project files, only create_bundle target with a
+  non-empty product_type will have a corresponding target in Xcode project.
+```
+### <a name="public"></a>**public**: Declare public header files for a target.
+
+```
+  A list of files that other targets can include. These permissions are checked
+  via the "check" command (see "gn help check").
+
+  If no public files are declared, other targets (assuming they have visibility
+  to depend on this target) can include any file in the sources list. If this
+  variable is defined on a target, dependent targets may only include files on
+  this whitelist unless that target is marked as a friend (see "gn help
+  friend").
+
+  Header file permissions are also subject to visibility. A target must be
+  visible to another target to include any files from it at all and the public
+  headers indicate which subset of those files are permitted. See "gn help
+  visibility" for more.
+
+  Public files are inherited through the dependency tree. So if there is a
+  dependency A -> B -> C, then A can include C's public headers. However, the
+  same is NOT true of visibility, so unless A is in C's visibility list, the
+  include will be rejected.
+
+  GN only knows about files declared in the "sources" and "public" sections of
+  targets. If a file is included that is not known to the build, it will be
+  allowed.
+
+  It is common for test targets to need to include private headers for their
+  associated code. In this case, list the test target in the "friend" list of
+  the target that owns the private header to allow the inclusion. See
+  "gn help friend" for more.
+```
+
+#### **Examples**
+
+```
+  These exact files are public:
+    public = [ "foo.h", "bar.h" ]
+
+  No files are public (no targets may include headers from this one):
+    public = []
+```
+### <a name="public_configs"></a>**public_configs**: Configs to be applied on dependents.
+
+```
+  A list of config labels.
+
+  Targets directly depending on this one will have the configs listed in this
+  variable added to them. These configs will also apply to the current target.
+
+  This addition happens in a second phase once a target and all of its
+  dependencies have been resolved. Therefore, a target will not see these
+  force-added configs in their "configs" variable while the script is running,
+  and they can not be removed. As a result, this capability should generally
+  only be used to add defines and include directories necessary to compile a
+  target's headers.
+
+  See also "all_dependent_configs".
+```
+
+#### **Ordering of flags and values**
+
+```
+  1. Those set on the current target (not in a config).
+  2. Those set on the "configs" on the target in order that the
+     configs appear in the list.
+  3. Those set on the "all_dependent_configs" on the target in order
+     that the configs appear in the list.
+  4. Those set on the "public_configs" on the target in order that
+     those configs appear in the list.
+  5. all_dependent_configs pulled from dependencies, in the order of
+     the "deps" list. This is done recursively. If a config appears
+     more than once, only the first occurence will be used.
+  6. public_configs pulled from dependencies, in the order of the
+     "deps" list. If a dependency is public, they will be applied
+     recursively.
+```
+### <a name="public_deps"></a>**public_deps**: Declare public dependencies.
+
+```
+  Public dependencies are like private dependencies (see "gn help deps") but
+  additionally express that the current target exposes the listed deps as part
+  of its public API.
+
+  This has several ramifications:
+
+    - public_configs that are part of the dependency are forwarded to direct
+      dependents.
+
+    - Public headers in the dependency are usable by dependents (includes do
+      not require a direct dependency or visibility).
+
+    - If the current target is a shared library, other shared libraries that it
+      publicly depends on (directly or indirectly) are propagated up the
+      dependency tree to dependents for linking.
+```
+
+#### **Discussion**
+
+```
+  Say you have three targets: A -> B -> C. C's visibility may allow B to depend
+  on it but not A. Normally, this would prevent A from including any headers
+  from C, and C's public_configs would apply only to B.
+
+  If B lists C in its public_deps instead of regular deps, A will now inherit
+  C's public_configs and the ability to include C's public headers.
+
+  Generally if you are writing a target B and you include C's headers as part
+  of B's public headers, or targets depending on B should consider B and C to
+  be part of a unit, you should use public_deps instead of deps.
+```
+
+#### **Example**
+
+```
+  # This target can include files from "c" but not from
+  # "super_secret_implementation_details".
+  executable("a") {
+    deps = [ ":b" ]
+  }
+
+  shared_library("b") {
+    deps = [ ":super_secret_implementation_details" ]
+    public_deps = [ ":c" ]
+  }
+```
+### <a name="response_file_contents"></a>**response_file_contents**: Contents of a response file for actions.
+
+```
+  Sometimes the arguments passed to a script can be too long for the system's
+  command-line capabilities. This is especially the case on Windows where the
+  maximum command-line length is less than 8K. A response file allows you to
+  pass an unlimited amount of data to a script in a temporary file for an
+  action or action_foreach target.
+
+  If the response_file_contents variable is defined and non-empty, the list
+  will be treated as script args (including possibly substitution patterns)
+  that will be written to a temporary file at build time. The name of the
+  temporary file will be substituted for "{{response_file_name}}" in the script
+  args.
+
+  The response file contents will always be quoted and escaped according to
+  Unix shell rules. To parse the response file, the Python script should use
+  "shlex.split(file_contents)".
+```
+
+#### **Example**
+
+```
+  action("process_lots_of_files") {
+    script = "process.py",
+    inputs = [ ... huge list of files ... ]
+
+    # Write all the inputs to a response file for the script. Also,
+    # make the paths relative to the script working directory.
+    response_file_contents = rebase_path(inputs, root_build_dir)
+
+    # The script expects the name of the response file in --file-list.
+    args = [
+      "--enable-foo",
+      "--file-list={{response_file_name}}",
+    ]
+  }
+```
+### <a name="script"></a>**script**: Script file for actions.
+
+```
+  An absolute or buildfile-relative file name of a Python script to run for a
+  action and action_foreach targets (see "gn help action" and "gn help
+  action_foreach").
+```
+### <a name="sources"></a>**sources**: Source files for a target
+
+```
+  A list of files. Non-absolute paths will be resolved relative to the current
+  build file.
+```
+
+#### **Sources for binary targets**
+
+```
+  For binary targets (source sets, executables, and libraries), the known file
+  types will be compiled with the associated tools. Unknown file types and
+  headers will be skipped. However, you should still list all C/C+ header files
+  so GN knows about the existence of those files for the purposes of include
+  checking.
+
+  As a special case, a file ending in ".def" will be treated as a Windows
+  module definition file. It will be appended to the link line with a
+  preceding "/DEF:" string. There must be at most one .def file in a target
+  and they do not cross dependency boundaries (so specifying a .def file in a
+  static library or source set will have no effect on the executable or shared
+  library they're linked into).
+```
+
+#### **Sources for non-binary targets**
+
+```
+  action_foreach
+    The sources are the set of files that the script will be executed over. The
+    script will run once per file.
+
+  action
+    The sources will be treated the same as inputs. See "gn help inputs" for
+    more information and usage advice.
+
+  copy
+    The source are the source files to copy.
+```
+### <a name="testonly"></a>**testonly**: Declares a target must only be used for testing.
+
+```
+  Boolean. Defaults to false.
+
+  When a target is marked "testonly = true", it must only be depended on by
+  other test-only targets. Otherwise, GN will issue an error that the
+  depenedency is not allowed.
+
+  This feature is intended to prevent accidentally shipping test code in a
+  final product.
+```
+
+#### **Example**
+
+```
+  source_set("test_support") {
+    testonly = true
+    ...
+  }
+```
+### <a name="visibility"></a>**visibility**: A list of labels that can depend on a target.
+
+```
+  A list of labels and label patterns that define which targets can depend on
+  the current one. These permissions are checked via the "check" command (see
+  "gn help check").
+
+  If visibility is not defined, it defaults to public ("*").
+
+  If visibility is defined, only the targets with labels that match it can
+  depend on the current target. The empty list means no targets can depend on
+  the current target.
+
+  Tip: Often you will want the same visibility for all targets in a BUILD file.
+  In this case you can just put the definition at the top, outside of any
+  target, and the targets will inherit that scope and see the definition.
+```
+
+#### **Patterns**
+
+```
+  See "gn help label_pattern" for more details on what types of patterns are
+  supported. If a toolchain is specified, only targets in that toolchain will
+  be matched. If a toolchain is not specified on a pattern, targets in all
+  toolchains will be matched.
+```
+
+#### **Examples**
+
+```
+  Only targets in the current buildfile ("private"):
+    visibility = [ ":*" ]
+
+  No targets (used for targets that should be leaf nodes):
+    visibility = []
+
+  Any target ("public", the default):
+    visibility = [ "*" ]
+
+  All targets in the current directory and any subdirectory:
+    visibility = [ "./*" ]
+
+  Any target in "//bar/BUILD.gn":
+    visibility = [ "//bar:*" ]
+
+  Any target in "//bar/" or any subdirectory thereof:
+    visibility = [ "//bar/*" ]
+
+  Just these specific targets:
+    visibility = [ ":mything", "//foo:something_else" ]
+
+  Any target in the current directory and any subdirectory thereof, plus
+  any targets in "//bar/" and any subdirectory thereof.
+    visibility = [ "./*", "//bar/*" ]
+```
+### <a name="write_runtime_deps"></a>**write_runtime_deps**: Writes the target's runtime_deps to the given path.
+
+```
+  Does not synchronously write the file, but rather schedules it to be written
+  at the end of generation.
+
+  If the file exists and the contents are identical to that being written, the
+  file will not be updated. This will prevent unnecessary rebuilds of targets
+  that depend on this file.
+
+  Path must be within the output directory.
+
+  See "gn help runtime_deps" for how the runtime dependencies are computed.
+
+  The format of this file will list one file per line with no escaping. The
+  files will be relative to the root_build_dir. The first line of the file will
+  be the main output file of the target itself. The file contents will be the
+  same as requesting the runtime deps be written on the command line (see "gn
+  help --runtime-deps-list-file").
+```
+### <a name="xcode_extra_attributes"></a>**xcode_extra_attributes**: [scope] Extra attributes for Xcode projects.
+
+```
+  The value defined in this scope will be copied to the EXTRA_ATTRIBUTES
+  property of the generated Xcode project. They are only meaningful when
+  generating with --ide=xcode.
+
+  See "gn help create_bundle" for more information.
+```
+### <a name="test_application_name"></a>**test_application_name**: Test application name for unit or ui test target.
+
+```
+  Each unit and ui test target must have a test application target, and this
+  value is used to specify the relationship. Only meaningful to Xcode (used as
+  part of the Xcode project generation).
+
+  See "gn help create_bundle" for more information.
+```
+
+#### **Exmaple**
+
+```
+  create_bundle("chrome_xctest") {
+    test_application_name = "chrome"
+    ...
+  }
+```
+## <a name="other"></a>Other help topics
+
+### <a name="buildargs"></a>**Build Arguments Overview**
+
+```
+  Build arguments are variables passed in from outside of the build that build
+  files can query to determine how the build works.
+```
+
+#### **How build arguments are set**
+
+```
+  First, system default arguments are set based on the current system. The
+  built-in arguments are:
+   - host_cpu
+   - host_os
+   - current_cpu
+   - current_os
+   - target_cpu
+   - target_os
+
+  Next, project-specific overrides are applied. These are specified inside
+  the default_args variable of //.gn. See "gn help dotfile" for more.
+
+  If specified, arguments from the --args command line flag are used. If that
+  flag is not specified, args from previous builds in the build directory will
+  be used (this is in the file args.gn in the build directory).
+
+  Last, for targets being compiled with a non-default toolchain, the toolchain
+  overrides are applied. These are specified in the toolchain_args section of a
+  toolchain definition. The use-case for this is that a toolchain may be
+  building code for a different platform, and that it may want to always
+  specify Posix, for example. See "gn help toolchain" for more.
+
+  If you specify an override for a build argument that never appears in a
+  "declare_args" call, a nonfatal error will be displayed.
+```
+
+#### **Examples**
+
+```
+  gn args out/FooBar
+      Create the directory out/FooBar and open an editor. You would type
+      something like this into that file:
+          enable_doom_melon=false
+          os="android"
+
+  gn gen out/FooBar --args="enable_doom_melon=true os=\"android\""
+      This will overwrite the build directory with the given arguments. (Note
+      that the quotes inside the args command will usually need to be escaped
+      for your shell to pass through strings values.)
+```
+
+#### **How build arguments are used**
+
+```
+  If you want to use an argument, you use declare_args() and specify default
+  values. These default values will apply if none of the steps listed in the
+  "How build arguments are set" section above apply to the given argument, but
+  the defaults will not override any of these.
+
+  Often, the root build config file will declare global arguments that will be
+  passed to all buildfiles. Individual build files can also specify arguments
+  that apply only to those files. It is also useful to specify build args in an
+  "import"-ed file if you want such arguments to apply to multiple buildfiles.
+```
+### <a name="dotfile"></a>**.gn file**
+
+```
+  When gn starts, it will search the current directory and parent directories
+  for a file called ".gn". This indicates the source root. You can override
+  this detection by using the --root command-line argument
+
+  The .gn file in the source root will be executed. The syntax is the same as a
+  buildfile, but with very limited build setup-specific meaning.
+
+  If you specify --root, by default GN will look for the file .gn in that
+  directory. If you want to specify a different file, you can additionally pass
+  --dotfile:
+
+    gn gen out/Debug --root=/home/build --dotfile=/home/my_gn_file.gn
+```
+
+#### **Variables**
+
+```
+  arg_file_template [optional]
+      Path to a file containing the text that should be used as the default
+      args.gn content when you run `gn args`.
+
+  buildconfig [required]
+      Path to the build config file. This file will be used to set up the
+      build file execution environment for each toolchain.
+
+  check_targets [optional]
+      A list of labels and label patterns that should be checked when running
+      "gn check" or "gn gen --check". If unspecified, all targets will be
+      checked. If it is the empty list, no targets will be checked.
+
+      The format of this list is identical to that of "visibility" so see "gn
+      help visibility" for examples.
+
+  exec_script_whitelist [optional]
+      A list of .gn/.gni files (not labels) that have permission to call the
+      exec_script function. If this list is defined, calls to exec_script will
+      be checked against this list and GN will fail if the current file isn't
+      in the list.
+
+      This is to allow the use of exec_script to be restricted since is easy to
+      use inappropriately. Wildcards are not supported. Files in the
+      secondary_source tree (if defined) should be referenced by ignoring the
+      secondary tree and naming them as if they are in the main tree.
+
+      If unspecified, the ability to call exec_script is unrestricted.
+
+      Example:
+        exec_script_whitelist = [
+          "//base/BUILD.gn",
+          "//build/my_config.gni",
+        ]
+
+  root [optional]
+      Label of the root build target. The GN build will start by loading the
+      build file containing this target name. This defaults to "//:" which will
+      cause the file //BUILD.gn to be loaded.
+
+  script_executable [optional]
+      Path to specific Python executable or potentially a different language
+      interpreter that is used to execute scripts in action targets and
+      exec_script calls.
+
+  secondary_source [optional]
+      Label of an alternate directory tree to find input files. When searching
+      for a BUILD.gn file (or the build config file discussed above), the file
+      will first be looked for in the source root. If it's not found, the
+      secondary source root will be checked (which would contain a parallel
+      directory hierarchy).
+
+      This behavior is intended to be used when BUILD.gn files can't be checked
+      in to certain source directories for whatever reason.
+
+      The secondary source root must be inside the main source tree.
+
+  default_args [optional]
+      Scope containing the default overrides for declared arguments. These
+      overrides take precedence over the default values specified in the
+      declare_args() block, but can be overriden using --args or the
+      args.gn file.
+
+      This is intended to be used when subprojects declare arguments with
+      default values that need to be changed for whatever reason.
+```
+
+#### **Example .gn file contents**
+
+```
+  buildconfig = "//build/config/BUILDCONFIG.gn"
+
+  check_targets = [
+    "//doom_melon/*",  # Check everything in this subtree.
+    "//tools:mind_controlling_ant",  # Check this specific target.
+  ]
+
+  root = "//:root"
+
+  secondary_source = "//build/config/temporary_buildfiles/"
+
+  default_args = {
+    # Default to release builds for this project.
+    is_debug = false
+    is_component_build = false
+  }
+```
+### <a name="execution"></a>**Build graph and execution overview**
+
+#### **Overall build flow**
+
+```
+  1. Look for ".gn" file (see "gn help dotfile") in the current directory and
+     walk up the directory tree until one is found. Set this directory to be
+     the "source root" and interpret this file to find the name of the build
+     config file.
+
+  2. Execute the build config file identified by .gn to set up the global
+     variables and default toolchain name. Any arguments, variables, defaults,
+     etc. set up in this file will be visible to all files in the build.
+
+  3. Load the //BUILD.gn (in the source root directory).
+
+  4. Recursively evaluate rules and load BUILD.gn in other directories as
+     necessary to resolve dependencies. If a BUILD file isn't found in the
+     specified location, GN will look in the corresponding location inside
+     the secondary_source defined in the dotfile (see "gn help dotfile").
+
+  5. When a target's dependencies are resolved, write out the `.ninja`
+     file to disk.
+
+  6. When all targets are resolved, write out the root build.ninja file.
+```
+
+#### **Executing target definitions and templates**
+
+```
+  Build files are loaded in parallel. This means it is impossible to
+  interrogate a target from GN code for any information not derivable from its
+  label (see "gn help label"). The exception is the get_target_outputs()
+  function which requires the target being interrogated to have been defined
+  previously in the same file.
+
+  Targets are declared by their type and given a name:
+
+    static_library("my_static_library") {
+      ... target parameter definitions ...
+    }
+
+  There is also a generic "target" function for programmatically defined types
+  (see "gn help target"). You can define new types using templates (see "gn
+  help template"). A template defines some custom code that expands to one or
+  more other targets.
+
+  Before executing the code inside the target's { }, the target defaults are
+  applied (see "gn help set_defaults"). It will inject implicit variable
+  definitions that can be overridden by the target code as necessary. Typically
+  this mechanism is used to inject a default set of configs that define the
+  global compiler and linker flags.
+```
+
+#### **Which targets are built**
+
+```
+  All targets encountered in the default toolchain (see "gn help toolchain")
+  will have build rules generated for them, even if no other targets reference
+  them. Their dependencies must resolve and they will be added to the implicit
+  "all" rule (see "gn help ninja_rules").
+
+  Targets in non-default toolchains will only be generated when they are
+  required (directly or transitively) to build a target in the default
+  toolchain.
+
+  See also "gn help ninja_rules".
+```
+
+#### **Dependencies**
+
+```
+  The only difference between "public_deps" and "deps" except for pushing
+  configs around the build tree and allowing includes for the purposes of "gn
+  check".
+
+  A target's "data_deps" are guaranteed to be built whenever the target is
+  built, but the ordering is not defined. The meaning of this is dependencies
+  required at runtime. Currently data deps will be complete before the target
+  is linked, but this is not semantically guaranteed and this is undesirable
+  from a build performance perspective. Since we hope to change this in the
+  future, do not rely on this behavior.
+```
+### <a name="grammar"></a>**Language and grammar for GN build files**
+
+#### **Tokens**
+
+```
+  GN build files are read as sequences of tokens.  While splitting the file
+  into tokens, the next token is the longest sequence of characters that form a
+  valid token.
+```
+
+#### **White space and comments**
+
+```
+  White space is comprised of spaces (U+0020), horizontal tabs (U+0009),
+  carriage returns (U+000D), and newlines (U+000A).
+
+  Comments start at the character "#" and stop at the next newline.
+
+  White space and comments are ignored except that they may separate tokens
+  that would otherwise combine into a single token.
+```
+
+#### **Identifiers**
+
+```
+  Identifiers name variables and functions.
+
+      identifier = letter { letter | digit } .
+      letter     = "A" ... "Z" | "a" ... "z" | "_" .
+      digit      = "0" ... "9" .
+```
+
+#### **Keywords**
+
+```
+  The following keywords are reserved and may not be used as identifiers:
+
+          else    false   if      true
+```
+
+#### **Integer literals**
+
+```
+  An integer literal represents a decimal integer value.
+
+      integer = [ "-" ] digit { digit } .
+
+  Leading zeros and negative zero are disallowed.
+```
+
+#### **String literals**
+
+```
+  A string literal represents a string value consisting of the quoted
+  characters with possible escape sequences and variable expansions.
+
+      string           = `"` { char | escape | expansion } `"` .
+      escape           = `\` ( "$" | `"` | char ) .
+      BracketExpansion = "{" ( identifier | ArrayAccess | ScopeAccess "
+                         ") "}" .
+      Hex              = "0x" [0-9A-Fa-f][0-9A-Fa-f]
+      expansion        = "$" ( identifier | BracketExpansion | Hex ) .
+      char             = /* any character except "$", `"`, or newline "
+                        "*/ .
+
+  After a backslash, certain sequences represent special characters:
+
+          \"    U+0022    quotation mark
+          \$    U+0024    dollar sign
+          \\    U+005C    backslash
+
+  All other backslashes represent themselves.
+
+  To insert an arbitrary byte value, use $0xFF. For example, to insert a
+  newline character: "Line one$0x0ALine two".
+
+  An expansion will evaluate the variable following the '$' and insert a
+  stringified version of it into the result. For example, to concat two path
+  components with a slash separating them:
+    "$var_one/$var_two"
+  Use the "${var_one}" format to be explicitly deliniate the variable for
+  otherwise-ambiguous cases.
+```
+
+#### **Punctuation**
+
+```
+  The following character sequences represent punctuation:
+
+          +       +=      ==      !=      (       )
+          -       -=      <       <=      [       ]
+          !       =       >       >=      {       }
+                          &&      ||      .       ,
+```
+
+#### **Grammar**
+
+```
+  The input tokens form a syntax tree following a context-free grammar:
+
+      File = StatementList .
+
+      Statement     = Assignment | Call | Condition .
+      LValue        = identifier | ArrayAccess | ScopeAccess .
+      Assignment    = LValue AssignOp Expr .
+      Call          = identifier "(" [ ExprList ] ")" [ Block ] .
+      Condition     = "if" "(" Expr ")" Block
+                      [ "else" ( Condition | Block ) ] .
+      Block         = "{" StatementList "}" .
+      StatementList = { Statement } .
+
+      ArrayAccess = identifier "[" Expr "]" .
+      ScopeAccess = identifier "." identifier .
+      Expr        = UnaryExpr | Expr BinaryOp Expr .
+      UnaryExpr   = PrimaryExpr | UnaryOp UnaryExpr .
+      PrimaryExpr = identifier | integer | string | Call
+                  | ArrayAccess | ScopeAccess | Block
+                  | "(" Expr ")"
+                  | "[" [ ExprList [ "," ] ] "]" .
+      ExprList    = Expr { "," Expr } .
+
+      AssignOp = "=" | "+=" | "-=" .
+      UnaryOp  = "!" .
+      BinaryOp = "+" | "-"                  // highest priority
+               | "<" | "<=" | ">" | ">="
+               | "==" | "!="
+               | "&&"
+               | "||" .                     // lowest priority
+
+  All binary operators are left-associative.
+```
+
+#### **Types**
+
+```
+  The GN language is dynamically typed. The following types are used:
+
+   - Boolean: Uses the keywords "true" and "false". There is no implicit
+     conversion between booleans and integers.
+
+   - Integers: All numbers in GN are signed 64-bit integers.
+
+   - Strings: Strings are 8-bit with no enforced encoding. When a string is
+     used to interact with other systems with particular encodings (like the
+     Windows and Mac filesystems) it is assumed to be UTF-8. See "String
+     literals" above for more.
+
+   - Lists: Lists are arbitrary-length ordered lists of values. See "Lists"
+     below for more.
+
+   - Scopes: Scopes are like dictionaries that use variable names for keys. See
+     "Scopes" below for more.
+```
+
+#### **Lists**
+
+```
+  Lists are created with [] and using commas to separate items:
+
+       mylist = [ 0, 1, 2, "some string" ]
+
+  A comma after the last item is optional. Lists are dereferenced using 0-based
+  indexing:
+
+       mylist[0] += 1
+       var = mylist[2]
+
+  Lists can be concatenated using the '+' and '+=' operators. Bare values can
+  not be concatenated with lists, to add a single item, it must be put into a
+  list of length one.
+
+  Items can be removed from lists using the '-' and '-=' operators. This will
+  remove all occurrences of every item in the right-hand list from the
+  left-hand list. It is an error to remove an item not in the list. This is to
+  prevent common typos and to detect dead code that is removing things that no
+  longer apply.
+
+  It is an error to use '=' to replace a nonempty list with another nonempty
+  list. This is to prevent accidentally overwriting data when in most cases
+  '+=' was intended. To overwrite a list on purpose, first assign it to the
+  empty list:
+
+    mylist = []
+    mylist = otherlist
+
+  When assigning to a list named 'sources' using '=' or '+=', list items may be
+  automatically filtered out. See "gn help set_sources_assignment_filter" for
+  more.
+```
+
+#### **Scopes**
+
+```
+  All execution happens in the context of a scope which holds the current state
+  (like variables). With the exception of loops and conditions, '{' introduces
+  a new scope that has a parent reference to the old scope.
+
+  Variable reads recursively search all nested scopes until the variable is
+  found or there are no more scopes. Variable writes always go into the current
+  scope. This means that after the closing '}' (again excepting loops and
+  conditions), all local variables will be restored to the previous values.
+  This also means that "foo = foo" can do useful work by copying a variable
+  into the current scope that was defined in a containing scope.
+
+  Scopes can also be assigned to variables. Such scopes can be created by
+  functions like exec_script, when invoking a template (the template code
+  refers to the variables set by the invoking code by the implicitly-created
+  "invoker" scope), or explicitly like:
+
+    empty_scope = {}
+    myvalues = {
+      foo = 21
+      bar = "something"
+    }
+
+  Inside such a scope definition can be any GN code including conditionals and
+  function calls. After the close of the scope, it will contain all variables
+  explicitly set by the code contained inside it. After this, the values can be
+  read, modified, or added to:
+
+    myvalues.foo += 2
+    empty_scope.new_thing = [ 1, 2, 3 ]
+```
+### <a name="input_conversion"></a>**input_conversion**: Specifies how to transform input to a variable.
+
+```
+  input_conversion is an argument to read_file and exec_script that specifies
+  how the result of the read operation should be converted into a variable.
+
+  "" (the default)
+      Discard the result and return None.
+
+  "list lines"
+      Return the file contents as a list, with a string for each line. The
+      newlines will not be present in the result. The last line may or may not
+      end in a newline.
+
+      After splitting, each individual line will be trimmed of whitespace on
+      both ends.
+
+  "scope"
+      Execute the block as GN code and return a scope with the resulting values
+      in it. If the input was:
+        a = [ "hello.cc", "world.cc" ]
+        b = 26
+      and you read the result into a variable named "val", then you could
+      access contents the "." operator on "val":
+        sources = val.a
+        some_count = val.b
+
+  "string"
+      Return the file contents into a single string.
+
+  "value"
+      Parse the input as if it was a literal rvalue in a buildfile. Examples of
+      typical program output using this mode:
+        [ "foo", "bar" ]     (result will be a list)
+      or
+        "foo bar"            (result will be a string)
+      or
+        5                    (result will be an integer)
+
+      Note that if the input is empty, the result will be a null value which
+      will produce an error if assigned to a variable.
+
+  "json"
+      Parse the input as a JSON and convert it to equivalent GN rvalue. The data
+      type mapping is:
+        a string in JSON maps to string in GN
+        an integer in JSON maps to integer in GN
+        a float in JSON is unsupported and will result in an error
+        an object in JSON maps to scope in GN
+        an array in JSON maps to list in GN
+        a boolean in JSON maps to boolean in GN
+        a null in JSON is unsupported and will result in an error
+
+      Nota that the dictionary keys have to be valid GN identifiers otherwise
+      they will produce an error.
+
+  "trim ..."
+      Prefixing any of the other transformations with the word "trim" will
+      result in whitespace being trimmed from the beginning and end of the
+      result before processing.
+
+      Examples: "trim string" or "trim list lines"
+
+      Note that "trim value" is useless because the value parser skips
+      whitespace anyway.
+```
+### <a name="label_pattern"></a>**Label patterns**
+
+```
+  A label pattern is a way of expressing one or more labels in a portion of the
+  source tree. They are not general regular expressions.
+
+  They can take the following forms only:
+
+   - Explicit (no wildcard):
+       "//foo/bar:baz"
+       ":baz"
+
+   - Wildcard target names:
+       "//foo/bar:*" (all targets in the //foo/bar/BUILD.gn file)
+       ":*"  (all targets in the current build file)
+
+   - Wildcard directory names ("*" is only supported at the end)
+       "*"  (all targets)
+       "//foo/bar/*"  (all targets in any subdir of //foo/bar)
+       "./*"  (all targets in the current build file or sub dirs)
+
+  Any of the above forms can additionally take an explicit toolchain. In this
+  case, the toolchain must be fully qualified (no wildcards are supported in
+  the toolchain name).
+
+    "//foo:bar(//build/toochain:mac)"
+        An explicit target in an explicit toolchain.
+
+    ":*(//build/toolchain/linux:32bit)"
+        All targets in the current build file using the 32-bit Linux toolchain.
+
+    "//foo/*(//build/toolchain:win)"
+        All targets in //foo and any subdirectory using the Windows
+        toolchain.
+```
+### <a name="labels"></a>**About labels**
+
+```
+  Everything that can participate in the dependency graph (targets, configs,
+  and toolchains) are identified by labels. A common label looks like:
+
+    //base/test:test_support
+
+  This consists of a source-root-absolute path, a colon, and a name. This means
+  to look for the thing named "test_support" in "base/test/BUILD.gn".
+
+  You can also specify system absolute paths if necessary. Typically such
+  paths would be specified via a build arg so the developer can specify where
+  the component is on their system.
+
+    /usr/local/foo:bar    (Posix)
+    /C:/Program Files/MyLibs:bar   (Windows)
+```
+
+#### **Toolchains**
+
+```
+  A canonical label includes the label of the toolchain being used. Normally,
+  the toolchain label is implicitly inherited from the current execution
+  context, but you can override this to specify cross-toolchain dependencies:
+
+    //base/test:test_support(//build/toolchain/win:msvc)
+
+  Here GN will look for the toolchain definition called "msvc" in the file
+  "//build/toolchain/win" to know how to compile this target.
+```
+
+#### **Relative labels**
+
+```
+  If you want to refer to something in the same buildfile, you can omit
+  the path name and just start with a colon. This format is recommended for
+  all same-file references.
+
+    :base
+
+  Labels can be specified as being relative to the current directory.
+  Stylistically, we prefer to use absolute paths for all non-file-local
+  references unless a build file needs to be run in different contexts (like a
+  project needs to be both standalone and pulled into other projects in
+  difference places in the directory hierarchy).
+
+    source/plugin:myplugin
+    ../net:url_request
+```
+
+#### **Implicit names**
+
+```
+  If a name is unspecified, it will inherit the directory name. Stylistically,
+  we prefer to omit the colon and name when possible:
+
+    //net  ->  //net:net
+    //tools/gn  ->  //tools/gn:gn
+```
+### <a name="ninja_rules"></a>**Ninja build rules**
+
+#### **The "all" and "default" rules**
+
+```
+  All generated targets (see "gn help execution") will be added to an implicit
+  build rule called "all" so "ninja all" will always compile everything. The
+  default rule will be used by Ninja if no specific target is specified (just
+  typing "ninja"). If there is a target named "default" in the root build file,
+  it will be the default build rule, otherwise the implicit "all" rule will be
+  used.
+```
+
+#### **Phony rules**
+
+```
+  GN generates Ninja "phony" rules for targets in the default toolchain.  The
+  phony rules can collide with each other and with the names of generated files
+  so are generated with the following priority:
+
+    1. Actual files generated by the build always take precedence.
+
+    2. Targets in the toplevel //BUILD.gn file.
+
+    3. Targets in toplevel directories matching the names of the directories.
+       So "ninja foo" can be used to compile "//foo:foo". This only applies to
+       the first level of directories since usually these are the most
+       important (so this won't apply to "//foo/bar:bar").
+
+    4. The short names of executables if there is only one executable with that
+       short name. Use "ninja doom_melon" to compile the
+       "//tools/fruit:doom_melon" executable.
+
+    5. The short names of all targets if there is only one target with that
+       short name.
+
+    6. Full label name with no leading slashes. So you can use
+       "ninja tools/fruit:doom_melon" to build "//tools/fruit:doom_melon".
+
+    7. Labels with an implicit name part (when the short names match the
+       directory). So you can use "ninja foo/bar" to compile "//foo/bar:bar".
+
+  These "phony" rules are provided only for running Ninja since this matches
+  people's historical expectations for building. For consistency with the rest
+  of the program, GN introspection commands accept explicit labels.
+
+  To explicitly compile a target in a non-default toolchain, you must give
+  Ninja the exact name of the output file relative to the build directory.
+```
+### <a name="nogncheck"></a>**nogncheck**: Skip an include line from checking.
+
+```
+  GN's header checker helps validate that the includes match the build
+  dependency graph. Sometimes an include might be conditional or otherwise
+  problematic, but you want to specifically allow it. In this case, it can be
+  whitelisted.
+
+  Include lines containing the substring "nogncheck" will be excluded from
+  header checking. The most common case is a conditional include:
+
+    #if defined(ENABLE_DOOM_MELON)
+    #include "tools/doom_melon/doom_melon.h"  // nogncheck
+    #endif
+
+  If the build file has a conditional dependency on the corresponding target
+  that matches the conditional include, everything will always link correctly:
+
+    source_set("mytarget") {
+      ...
+      if (enable_doom_melon) {
+        defines = [ "ENABLE_DOOM_MELON" ]
+        deps += [ "//tools/doom_melon" ]
+      }
+
+  But GN's header checker does not understand preprocessor directives, won't
+  know it matches the build dependencies, and will flag this include as
+  incorrect when the condition is false.
+```
+
+#### **More information**
+
+```
+  The topic "gn help check" has general information on how checking works and
+  advice on fixing problems. Targets can also opt-out of checking, see
+  "gn help check_includes".
+```
+### <a name="runtime_deps"></a>**Runtime dependencies**
+
+```
+  Runtime dependencies of a target are exposed via the "runtime_deps" category
+  of "gn desc" (see "gn help desc") or they can be written at build generation
+  time via write_runtime_deps(), or --runtime-deps-list-file (see "gn help
+  --runtime-deps-list-file").
+
+  To a first approximation, the runtime dependencies of a target are the set of
+  "data" files, data directories, and the shared libraries from all transitive
+  dependencies. Executables, shared libraries, and loadable modules are
+  considered runtime dependencies of themselves.
+```
+
+#### **Executables**
+
+```
+  Executable targets and those executable targets' transitive dependencies are
+  not considered unless that executable is listed in "data_deps". Otherwise, GN
+  assumes that the executable (and everything it requires) is a build-time
+  dependency only.
+```
+
+#### **Actions and copies**
+
+```
+  Action and copy targets that are listed as "data_deps" will have all of their
+  outputs and data files considered as runtime dependencies. Action and copy
+  targets that are "deps" or "public_deps" will have only their data files
+  considered as runtime dependencies. These targets can list an output file in
+  both the "outputs" and "data" lists to force an output file as a runtime
+  dependency in all cases.
+
+  The different rules for deps and data_deps are to express build-time (deps)
+  vs. run-time (data_deps) outputs. If GN counted all build-time copy steps as
+  data dependencies, there would be a lot of extra stuff, and if GN counted all
+  run-time dependencies as regular deps, the build's parallelism would be
+  unnecessarily constrained.
+
+  This rule can sometimes lead to unintuitive results. For example, given the
+  three targets:
+    A  --[data_deps]-->  B  --[deps]-->  ACTION
+  GN would say that A does not have runtime deps on the result of the ACTION,
+  which is often correct. But the purpose of the B target might be to collect
+  many actions into one logic unit, and the "data"-ness of A's dependency is
+  lost. Solutions:
+
+   - List the outputs of the action in its data section (if the results of
+     that action are always runtime files).
+   - Have B list the action in data_deps (if the outputs of the actions are
+     always runtime files).
+   - Have B list the action in both deps and data deps (if the outputs might be
+     used in both contexts and you don't care about unnecessary entries in the
+     list of files required at runtime).
+   - Split B into run-time and build-time versions with the appropriate "deps"
+     for each.
+```
+
+#### **Static libraries and source sets**
+
+```
+  The results of static_library or source_set targets are not considered
+  runtime dependencies since these are assumed to be intermediate targets only.
+  If you need to list a static library as a runtime dependency, you can
+  manually compute the .a/.lib file name for the current platform and list it
+  in the "data" list of a target (possibly on the static library target
+  itself).
+```
+
+#### **Multiple outputs**
+
+```
+  Linker tools can specify which of their outputs should be considered when
+  computing the runtime deps by setting runtime_outputs. If this is unset on
+  the tool, the default will be the first output only.
+```
+### <a name="source_expansion"></a>**How Source Expansion Works**
+
+```
+  Source expansion is used for the action_foreach and copy target types to map
+  source file names to output file names or arguments.
+
+  To perform source expansion in the outputs, GN maps every entry in the
+  sources to every entry in the outputs list, producing the cross product of
+  all combinations, expanding placeholders (see below).
+
+  Source expansion in the args works similarly, but performing the placeholder
+  substitution produces a different set of arguments for each invocation of the
+  script.
+
+  If no placeholders are found, the outputs or args list will be treated as a
+  static list of literal file names that do not depend on the sources.
+
+  See "gn help copy" and "gn help action_foreach" for more on how this is
+  applied.
+```
+
+#### **Placeholders**
+
+```
+  This section discusses only placeholders for actions. There are other
+  placeholders used in the definition of tools. See "gn help tool" for those.
+
+  {{source}}
+      The name of the source file including directory (*). This will generally
+      be used for specifying inputs to a script in the "args" variable.
+        "//foo/bar/baz.txt" => "../../foo/bar/baz.txt"
+
+  {{source_file_part}}
+      The file part of the source including the extension.
+        "//foo/bar/baz.txt" => "baz.txt"
+
+  {{source_name_part}}
+      The filename part of the source file with no directory or extension. This
+      will generally be used for specifying a transformation from a source file
+      to a destination file with the same name but different extension.
+        "//foo/bar/baz.txt" => "baz"
+
+  {{source_dir}}
+      The directory (*) containing the source file with no trailing slash.
+        "//foo/bar/baz.txt" => "../../foo/bar"
+
+  {{source_root_relative_dir}}
+      The path to the source file's directory relative to the source root, with
+      no leading "//" or trailing slashes. If the path is system-absolute,
+      (beginning in a single slash) this will just return the path with no
+      trailing slash. This value will always be the same, regardless of whether
+      it appears in the "outputs" or "args" section.
+        "//foo/bar/baz.txt" => "foo/bar"
+
+  {{source_gen_dir}}
+      The generated file directory (*) corresponding to the source file's path.
+      This will be different than the target's generated file directory if the
+      source file is in a different directory than the BUILD.gn file.
+        "//foo/bar/baz.txt" => "gen/foo/bar"
+
+  {{source_out_dir}}
+      The object file directory (*) corresponding to the source file's path,
+      relative to the build directory. this us be different than the target's
+      out directory if the source file is in a different directory than the
+      build.gn file.
+        "//foo/bar/baz.txt" => "obj/foo/bar"
+
+  {{source_target_relative}}
+      The path to the source file relative to the target's directory. This will
+      generally be used for replicating the source directory layout in the
+      output directory. This can only be used in actions and it is an error to
+      use in process_file_template where there is no "target".
+        "//foo/bar/baz.txt" => "baz.txt"
+```
+
+#### **(*) Note on directories**
+
+```
+  Paths containing directories (except the source_root_relative_dir) will be
+  different depending on what context the expansion is evaluated in. Generally
+  it should "just work" but it means you can't concatenate strings containing
+  these values with reasonable results.
+
+  Details: source expansions can be used in the "outputs" variable, the "args"
+  variable, and in calls to "process_file_template". The "args" are passed to a
+  script which is run from the build directory, so these directories will
+  relative to the build directory for the script to find. In the other cases,
+  the directories will be source- absolute (begin with a "//") because the
+  results of those expansions will be handled by GN internally.
+```
+
+#### **Examples**
+
+```
+  Non-varying outputs:
+    action("hardcoded_outputs") {
+      sources = [ "input1.idl", "input2.idl" ]
+      outputs = [ "$target_out_dir/output1.dat",
+                  "$target_out_dir/output2.dat" ]
+    }
+  The outputs in this case will be the two literal files given.
+
+  Varying outputs:
+    action_foreach("varying_outputs") {
+      sources = [ "input1.idl", "input2.idl" ]
+      outputs = [ "{{source_gen_dir}}/{{source_name_part}}.h",
+                  "{{source_gen_dir}}/{{source_name_part}}.cc" ]
+    }
+  Performing source expansion will result in the following output names:
+    //out/Debug/obj/mydirectory/input1.h
+    //out/Debug/obj/mydirectory/input1.cc
+    //out/Debug/obj/mydirectory/input2.h
+    //out/Debug/obj/mydirectory/input2.cc
+```
+## <a name="switches"></a>Command Line Switches
+
+**Available global switches
+**  Do "gn help --the_switch_you_want_help_on" for more. Individual
+  commands may take command-specific switches not listed here. See the
+  help on your specific command for more.
+
+```
+    *   [--args: Specifies build arguments overrides.](#--args)
+    *   [--color: Force colored output.](#--color)
+    *   [--dotfile: Override the name of the ".gn" file.](#--dotfile)
+    *   [--fail-on-unused-args: Treat unused build args as fatal errors.](#--fail-on-unused-args)
+    *   [--markdown: Write help output in the Markdown format.](#--markdown)
+    *   [--nocolor: Force non-colored output.](#--nocolor)
+    *   [-q: Quiet mode. Don't print output on success.](#-q)
+    *   [--root: Explicitly specify source root.](#--root)
+    *   [--runtime-deps-list-file: Save runtime dependencies for targets in file.](#--runtime-deps-list-file)
+    *   [--script-executable: Set the executable used to execute scripts.](#--script-executable)
+    *   [--threads: Specify number of worker threads.](#--threads)
+    *   [--time: Outputs a summary of how long everything took.](#--time)
+    *   [--tracelog: Writes a Chrome-compatible trace log to the given file.](#--tracelog)
+    *   [-v: Verbose logging.](#-v)
+    *   [--version: Prints the GN version number and exits.](#--version)
+```
+