diff --git a/tools/gn/args.cc b/tools/gn/args.cc
index 9f86016..7285d7a 100644
--- a/tools/gn/args.cc
+++ b/tools/gn/args.cc
@@ -11,13 +11,13 @@
 const char kBuildArgs_Help[] =
     R"(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.
+  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:
+  First, system default arguments are set based on the current system. The
+  built-in arguments are:
    - host_cpu
    - host_os
    - current_cpu
@@ -25,20 +25,18 @@
    - target_cpu
    - target_os
 
-  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).
+  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.
+  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.
+  If you specify an override for a build argument that never appears in a
+  "declare_args" call, a nonfatal error will be displayed.
 
 Examples
 
@@ -49,22 +47,21 @@
           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.)
+      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.
+  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.
+  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.
 )";
 
 namespace {
diff --git a/tools/gn/command_analyze.cc b/tools/gn/command_analyze.cc
index 03519cb..ee3774c 100644
--- a/tools/gn/command_analyze.cc
+++ b/tools/gn/command_analyze.cc
@@ -21,81 +21,75 @@
 const char kAnalyze_HelpShort[] =
     "analyze: Analyze which targets are affected by a list of files.";
 const char kAnalyze_Help[] =
-    "gn analyze <out_dir> <input_path> <output_path>\n"
-    "\n"
-    "  Analyze which targets are affected by a list of files.\n"
-    "\n"
-    "  This command takes three arguments:\n"
-    "\n"
-    "  out_dir is the path to the build directory.\n"
-    "\n"
-    "  input_path is a path to a file containing a JSON object with three\n"
-    "  fields:\n"
-    "\n"
-    "   - \"files\": A list of the filenames to check.\n"
-    "\n"
-    "   - \"test_targets\": A list of the labels for targets that\n"
-    "     are needed to run the tests we wish to run.\n"
-    "\n"
-    "   - \"additional_compile_targets\": A list of the labels for\n"
-    "     targets that we wish to rebuild, but aren't necessarily needed\n"
-    "     for testing. The important difference between this field and\n"
-    "     \"test_targets\" is that if an item in the\n"
-    "     additional_compile_targets list refers to a group, then\n"
-    "     any dependencies of that group will be returned if they are out\n"
-    "     of date, but the group itself does not need to be. If the\n"
-    "     dependencies themselves are groups, the same filtering is\n"
-    "     repeated. This filtering can be used to avoid rebuilding\n"
-    "     dependencies of a group that are unaffected by the input files.\n"
-    "     The list may also contain the string \"all\" to refer to a\n"
-    "     pseudo-group that contains every root target in the build\n"
-    "     graph.\n"
-    "\n"
-    "     This filtering behavior is also known as \"pruning\" the list\n"
-    "     of compile targets.\n"
-    "\n"
-    "  output_path is a path indicating where the results of the command\n"
-    "  are to be written. The results will be a file containing a JSON\n"
-    "  object with one or more of following fields:\n"
-    "\n"
-    "   - \"compile_targets\": A list of the labels derived from the input\n"
-    "     compile_targets list that are affected by the input files.\n"
-    "     Due to the way the filtering works for compile targets as\n"
-    "     described above, this list may contain targets that do not appear\n"
-    "     in the input list.\n"
-    "\n"
-    "   - \"test_targets\": A list of the labels from the input\n"
-    "     test_targets list that are affected by the input files. This list\n"
-    "     will be a proper subset of the input list.\n"
-    "\n"
-    "   - \"invalid_targets\": A list of any names from the input that\n"
-    "     do not exist in the build graph. If this list is non-empty,\n"
-    "     the \"error\" field will also be set to \"Invalid targets\".\n"
-    "\n"
-    "   - \"status\": A string containing one of three values:\n"
-    "\n"
-    "       - \"Found dependency\"\n"
-    "       - \"No dependency\"\n"
-    "       - \"Found dependency (all)\"\n"
-    "\n"
-    "     In the first case, the lists returned in compile_targets and\n"
-    "     test_targets should be passed to ninja to build. In the second\n"
-    "     case, nothing was affected and no build is necessary. In the third\n"
-    "     case, GN could not determine the correct answer and returned the\n"
-    "     input as the output in order to be safe.\n"
-    "\n"
-    "   - \"error\": This will only be present if an error occurred, and\n"
-    "     will contain a string describing the error. This includes cases\n"
-    "     where the input file is not in the right format, or contains\n"
-    "     invalid targets.\n"
+    R"(gn analyze <out_dir> <input_path> <output_path>
 
-    "  The command returns 1 if it is unable to read the input file or write\n"
-    "  the output file, or if there is something wrong with the build such\n"
-    "  that gen would also fail, and 0 otherwise. In particular, it returns\n"
-    "  0 even if the \"error\" key is non-empty and a non-fatal error\n"
-    "  occurred. In other words, it tries really hard to always write\n"
-    "  something to the output JSON and convey errors that way rather than\n"
-    "  via return codes.\n";
+  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.
+)";
 
 int RunAnalyze(const std::vector<std::string>& args) {
   if (args.size() != 3) {
diff --git a/tools/gn/command_args.cc b/tools/gn/command_args.cc
index 3b3dde6..374a274 100644
--- a/tools/gn/command_args.cc
+++ b/tools/gn/command_args.cc
@@ -280,62 +280,63 @@
 extern const char kArgs_HelpShort[] =
     "args: Display or configure arguments declared by the build.";
 extern const char kArgs_Help[] =
-    "gn args <out_dir> [--list] [--short] [--args]\n"
-    "\n"
-    "  See also \"gn help buildargs\" for a more high-level overview of how\n"
-    "  build arguments work.\n"
-    "\n"
-    "Usage\n"
-    "  gn args <out_dir>\n"
-    "      Open the arguments for the given build directory in an editor\n"
-    "      (as specified by the EDITOR environment variable). If the given\n"
-    "      build directory doesn't exist, it will be created and an empty\n"
-    "      args file will be opened in the editor. You would type something\n"
-    "      like this into that file:\n"
-    "          enable_doom_melon=false\n"
-    "          os=\"android\"\n"
-    "\n"
-    "      Note: you can edit the build args manually by editing the file\n"
-    "      \"args.gn\" in the build directory and then running\n"
-    "      \"gn gen <out_dir>\".\n"
-    "\n"
-    "  gn args <out_dir> --list[=<exact_arg>] [--short]\n"
-    "      Lists all build arguments available in the current configuration,\n"
-    "      or, if an exact_arg is specified for the list flag, just that one\n"
-    "      build argument.\n"
-    "\n"
-    "      The output will list the declaration location, default value, and\n"
-    "      comment preceeding the declaration. If --short is specified,\n"
-    "      only the names and values will be printed.\n"
-    "\n"
-    "      If the out_dir is specified, the build configuration will be\n"
-    "      taken from that build directory. The reason this is needed is that\n"
-    "      the definition of some arguments is dependent on the build\n"
-    "      configuration, so setting some values might add, remove, or change\n"
-    "      the default values for other arguments. Specifying your exact\n"
-    "      configuration allows the proper arguments to be displayed.\n"
-    "\n"
-    "      Instead of specifying the out_dir, you can also use the\n"
-    "      command-line flag to specify the build configuration:\n"
-    "        --args=<exact list of args to use>\n"
-    "\n"
-    "Examples\n"
-    "  gn args out/Debug\n"
-    "    Opens an editor with the args for out/Debug.\n"
-    "\n"
-    "  gn args out/Debug --list --short\n"
-    "    Prints all arguments with their default values for the out/Debug\n"
-    "    build.\n"
-    "\n"
-    "  gn args out/Debug --list=target_cpu\n"
-    "    Prints information about the \"target_cpu\" argument for the "
-        "out/Debug\n"
-    "    build.\n"
-    "\n"
-    "  gn args --list --args=\"os=\\\"android\\\" enable_doom_melon=true\"\n"
-    "    Prints all arguments with the default values for a build with the\n"
-    "    given arguments set (which may affect the values of other\n"
-    "    arguments).\n";
+    R"(gn args <out_dir> [--list] [--short] [--args]
+
+  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 (as
+      specified by the EDITOR environment variable). 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"
+
+      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]
+      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, default value, and comment
+      preceeding the declaration. If --short is specified, only the names and
+      values will be printed.
+
+      If the out_dir is specified, the build configuration will be taken from
+      that build directory. The reason this is needed is that the definition of
+      some arguments is dependent on the build configuration, so setting some
+      values might add, remove, or change the default values for other
+      arguments. Specifying your exact configuration allows the proper
+      arguments to be displayed.
+
+      Instead of specifying the out_dir, you can also use the command-line flag
+      to specify the build configuration:
+        --args=<exact list of args to use>
+
+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=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).
+)";
 
 int RunArgs(const std::vector<std::string>& args) {
   if (args.size() != 1) {
diff --git a/tools/gn/command_check.cc b/tools/gn/command_check.cc
index 467644b..86caf85 100644
--- a/tools/gn/command_check.cc
+++ b/tools/gn/command_check.cc
@@ -17,157 +17,153 @@
 namespace commands {
 
 const char kNoGnCheck_Help[] =
-    "nogncheck: Skip an include line from checking.\n"
-    "\n"
-    "  GN's header checker helps validate that the includes match the build\n"
-    "  dependency graph. Sometimes an include might be conditional or\n"
-    "  otherwise problematic, but you want to specifically allow it. In this\n"
-    "  case, it can be whitelisted.\n"
-    "\n"
-    "  Include lines containing the substring \"nogncheck\" will be excluded\n"
-    "  from header checking. The most common case is a conditional include:\n"
-    "\n"
-    "    #if defined(ENABLE_DOOM_MELON)\n"
-    "    #include \"tools/doom_melon/doom_melon.h\"  // nogncheck\n"
-    "    #endif\n"
-    "\n"
-    "  If the build file has a conditional dependency on the corresponding\n"
-    "  target that matches the conditional include, everything will always\n"
-    "  link correctly:\n"
-    "\n"
-    "    source_set(\"mytarget\") {\n"
-    "      ...\n"
-    "      if (enable_doom_melon) {\n"
-    "        defines = [ \"ENABLE_DOOM_MELON\" ]\n"
-    "        deps += [ \"//tools/doom_melon\" ]\n"
-    "      }\n"
-    "\n"
-    "  But GN's header checker does not understand preprocessor directives,\n"
-    "  won't know it matches the build dependencies, and will flag this\n"
-    "  include as incorrect when the condition is false.\n"
-    "\n"
-    "More information\n"
-    "\n"
-    "  The topic \"gn help check\" has general information on how checking\n"
-    "  works and advice on fixing problems. Targets can also opt-out of\n"
-    "  checking, see \"gn help check_includes\".\n";
+    R"(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".
+)";
 
 const char kCheck[] = "check";
 const char kCheck_HelpShort[] =
     "check: Check header dependencies.";
 const char kCheck_Help[] =
-    "gn check <out_dir> [<label_pattern>] [--force]\n"
-    "\n"
-    "  GN's include header checker validates that the includes for C-like\n"
-    "  source files match the build dependency graph.\n"
-    "\n"
-    "  \"gn check\" is the same thing as \"gn gen\" with the \"--check\" flag\n"
-    "  except that this command does not write out any build files. It's\n"
-    "  intended to be an easy way to manually trigger include file checking.\n"
-    "\n"
-    "  The <label_pattern> can take exact labels or patterns that match more\n"
-    "  than one (although not general regular expressions). If specified,\n"
-    "  only those matching targets will be checked. See\n"
-    "  \"gn help label_pattern\" for details.\n"
-    "\n"
-    "Command-specific switches\n"
-    "\n"
-    "  --force\n"
-    "      Ignores specifications of \"check_includes = false\" and checks\n"
-    "      all target's files that match the target label.\n"
-    "\n"
-    "What gets checked\n"
-    "\n"
-    "  The .gn file may specify a list of targets to be checked. Only these\n"
-    "  targets will be checked if no label_pattern is specified on the\n"
-    "  command line. Otherwise, the command-line list is used instead. See\n"
-    "  \"gn help dotfile\".\n"
-    "\n"
-    "  Targets can opt-out from checking with \"check_includes = false\"\n"
-    "  (see \"gn help check_includes\").\n"
-    "\n"
-    "  For targets being checked:\n"
-    "\n"
-    "    - GN opens all C-like source files in the targets to be checked and\n"
-    "      scans the top for includes.\n"
-    "\n"
-    "    - Includes with a \"nogncheck\" annotation are skipped (see\n"
-    "      \"gn help nogncheck\").\n"
-    "\n"
-    "    - Only includes using \"quotes\" are checked. <brackets> are assumed\n"
-    "      to be system includes.\n"
-    "\n"
-    "    - Include paths are assumed to be relative to either the source root\n"
-    "      or the \"root_gen_dir\" and must include all the path components.\n"
-    "      (It might be nice in the future to incorporate GN's knowledge of\n"
-    "      the include path to handle other include styles.)\n"
-    "\n"
-    "    - GN does not run the preprocessor so will not understand\n"
-    "      conditional includes.\n"
-    "\n"
-    "    - Only includes matching known files in the build are checked:\n"
-    "      includes matching unknown paths are ignored.\n"
-    "\n"
-    "  For an include to be valid:\n"
-    "\n"
-    "    - The included file must be in the current target, or there must\n"
-    "      be a path following only public dependencies to a target with the\n"
-    "      file in it (\"gn path\" is a good way to diagnose problems).\n"
-    "\n"
-    "    - There can be multiple targets with an included file: only one\n"
-    "      needs to be valid for the include to be allowed.\n"
-    "\n"
-    "    - If there are only \"sources\" in a target, all are considered to\n"
-    "      be public and can be included by other targets with a valid public\n"
-    "      dependency path.\n"
-    "\n"
-    "    - If a target lists files as \"public\", only those files are\n"
-    "      able to be included by other targets. Anything in the sources\n"
-    "      will be considered private and will not be includable regardless\n"
-    "      of dependency paths.\n"
-    "\n"
-    "    - Ouptuts from actions are treated like public sources on that\n"
-    "      target.\n"
-    "\n"
-    "    - A target can include headers from a target that depends on it\n"
-    "      if the other target is annotated accordingly. See\n"
-    "      \"gn help allow_circular_includes_from\".\n"
-    "\n"
-    "Advice on fixing problems\n"
-    "\n"
-    "  If you have a third party project that uses relative includes,\n"
-    "  it's generally best to exclude that target from checking altogether\n"
-    "  via \"check_includes = false\".\n"
-    "\n"
-    "  If you have conditional includes, make sure the build conditions\n"
-    "  and the preprocessor conditions match, and annotate the line with\n"
-    "  \"nogncheck\" (see \"gn help nogncheck\" for an example).\n"
-    "\n"
-    "  If two targets are hopelessly intertwined, use the\n"
-    "  \"allow_circular_includes_from\" annotation. Ideally each should have\n"
-    "  identical dependencies so configs inherited from those dependencies\n"
-    "  are consistent (see \"gn help allow_circular_includes_from\").\n"
-    "\n"
-    "  If you have a standalone header file or files that need to be shared\n"
-    "  between a few targets, you can consider making a source_set listing\n"
-    "  only those headers as public sources. With only header files, the\n"
-    "  source set will be a no-op from a build perspective, but will give a\n"
-    "  central place to refer to those headers. That source set's files\n"
-    "  will still need to pass \"gn check\" in isolation.\n"
-    "\n"
-    "  In rare cases it makes sense to list a header in more than one\n"
-    "  target if it could be considered conceptually a member of both.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gn check out/Debug\n"
-    "      Check everything.\n"
-    "\n"
-    "  gn check out/Default //foo:bar\n"
-    "      Check only the files in the //foo:bar target.\n"
-    "\n"
-    "  gn check out/Default \"//foo/*\n"
-    "      Check only the files in targets in the //foo directory tree.\n";
+    R"(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 either the source root or the
+      "root_gen_dir" and must include all the path components. (It might be
+      nice in the future to incorporate GN's knowledge of the include path to
+      handle other include styles.)
+
+    - 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.
+
+    - Ouptuts 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 uses relative includes, 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.
+)";
 
 int RunCheck(const std::vector<std::string>& args) {
   if (args.size() != 1 && args.size() != 2) {
diff --git a/tools/gn/command_desc.cc b/tools/gn/command_desc.cc
index 27117c5..2257221 100644
--- a/tools/gn/command_desc.cc
+++ b/tools/gn/command_desc.cc
@@ -291,134 +291,133 @@
 const char kDesc_HelpShort[] =
     "desc: Show lots of insightful information about a target or config.";
 const char kDesc_Help[] =
-    "gn desc <out_dir> <label or pattern> [<what to show>] [--blame] "
-    "[--format=json]\n"
-    "\n"
-    "  Displays information about a given target or config. The build\n"
-    "  build parameters will be taken for the build in the given <out_dir>.\n"
-    "\n"
-    "  The <label or pattern> can be a target label, a config label, or a\n"
-    "  label pattern (see \"gn help label_pattern\"). A label pattern will\n"
-    "  only match targets.\n"
-    "\n"
-    "Possibilities for <what to show>\n"
-    "\n"
-    "  (If unspecified an overall summary will be displayed.)\n"
-    "\n"
-    "  all_dependent_configs\n"
-    "  allow_circular_includes_from\n"
-    "  arflags [--blame]\n"
-    "  args\n"
-    "  cflags [--blame]\n"
-    "  cflags_cc [--blame]\n"
-    "  cflags_cxx [--blame]\n"
-    "  check_includes\n"
-    "  configs [--tree] (see below)\n"
-    "  defines [--blame]\n"
-    "  depfile\n"
-    "  deps [--all] [--tree] (see below)\n"
-    "  include_dirs [--blame]\n"
-    "  inputs\n"
-    "  ldflags [--blame]\n"
-    "  lib_dirs\n"
-    "  libs\n"
-    "  outputs\n"
-    "  public_configs\n"
-    "  public\n"
-    "  script\n"
-    "  sources\n"
-    "  testonly\n"
-    "  visibility\n"
-    "\n"
-    "  runtime_deps\n"
-    "      Compute all runtime deps for the given target. This is a\n"
-    "      computed list and does not correspond to any GN variable, unlike\n"
-    "      most other values here.\n"
-    "\n"
-    "      The output is a list of file names relative to the build\n"
-    "      directory. See \"gn help runtime_deps\" for how this is computed.\n"
-    "      This also works with \"--blame\" to see the source of the\n"
-    "      dependency.\n"
-    "\n"
-    "Shared flags\n"
-    "\n"
-    ALL_TOOLCHAINS_SWITCH_HELP
-    "\n"
-    "  --format=json\n"
-    "      Format the output as JSON instead of text.\n"
-    "\n"
-    "Target flags\n"
-    "\n"
-    "  --blame\n"
-    "      Used with any value specified on a config, this will name\n"
-    "      the config that cause that target to get the flag. This doesn't\n"
-    "      currently work for libs and lib_dirs because those are inherited\n"
-    "      and are more complicated to figure out the blame (patches\n"
-    "      welcome).\n"
-    "\n"
-    "Configs\n"
-    "\n"
-    "  The \"configs\" section will list all configs that apply. For targets\n"
-    "  this will include configs specified in the \"configs\" variable of\n"
-    "  the target, and also configs pushed onto this target via public\n"
-    "  or \"all dependent\" configs.\n"
-    "\n"
-    "  Configs can have child configs. Specifying --tree will show the\n"
-    "  hierarchy.\n"
-    "\n"
-    "Printing outputs\n"
-    "\n"
-    "  The \"outputs\" section will list all outputs that apply, including\n"
-    "  the outputs computed from the tool definition (eg for \"executable\",\n"
-    "  \"static_library\", ... targets).\n"
-    "\n"
-    "Printing deps\n"
-    "\n"
-    "  Deps will include all public, private, and data deps (TODO this could\n"
-    "  be clarified and enhanced) sorted in order applying. The following\n"
-    "  may be used:\n"
-    "\n"
-    "  --all\n"
-    "      Collects all recursive dependencies and prints a sorted flat list.\n"
-    "      Also usable with --tree (see below).\n"
-    "\n"
+    R"(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_SWITCH_HELP
+
+R"(
+  --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).
+)"
+
     TARGET_PRINTING_MODE_COMMAND_LINE_HELP
-    "\n"
+"\n"
     TARGET_TESTONLY_FILTER_COMMAND_LINE_HELP
-    "\n"
-    "  --tree\n"
-    "      Print a dependency tree. By default, duplicates will be elided\n"
-    "      with \"...\" but when --all and -tree are used together, no\n"
-    "      eliding will be performed.\n"
-    "\n"
-    "      The \"deps\", \"public_deps\", and \"data_deps\" will all be\n"
-    "      included in the tree.\n"
-    "\n"
-    "      Tree output can not be used with the filtering or output flags:\n"
-    "      --as, --type, --testonly.\n"
-    "\n"
-    TARGET_TYPE_FILTER_COMMAND_LINE_HELP
-    "\n"
-    "Note\n"
-    "\n"
-    "  This command will show the full name of directories and source files,\n"
-    "  but when directories and source paths are written to the build file,\n"
-    "  they will be adjusted to be relative to the build directory. So the\n"
-    "  values for paths displayed by this command won't match (but should\n"
-    "  mean the same thing).\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gn desc out/Debug //base:base\n"
-    "      Summarizes the given target.\n"
-    "\n"
-    "  gn desc out/Foo :base_unittests deps --tree\n"
-    "      Shows a dependency tree of the \"base_unittests\" project in\n"
-    "      the current directory.\n"
-    "\n"
-    "  gn desc out/Debug //base defines --blame\n"
-    "      Shows defines set for the //base:base target, annotated by where\n"
-    "      each one was set from.\n";
+
+R"(
+  --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.
+)"
+
+TARGET_TYPE_FILTER_COMMAND_LINE_HELP
+
+R"(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.
+)";
 
 int RunDesc(const std::vector<std::string>& args) {
   if (args.size() != 2 && args.size() != 3) {
diff --git a/tools/gn/command_format.cc b/tools/gn/command_format.cc
index 282f567..0849762 100644
--- a/tools/gn/command_format.cc
+++ b/tools/gn/command_format.cc
@@ -32,43 +32,44 @@
 const char kFormat_HelpShort[] =
     "format: Format .gn file.";
 const char kFormat_Help[] =
-    "gn format [--dump-tree] (--stdin | <build_file>)\n"
-    "\n"
-    "  Formats .gn file to a standard format.\n"
-    "\n"
-    "  The contents of some lists ('sources', 'deps', etc.) will be sorted to\n"
-    "  a canonical order. To suppress this, you can add a comment of the form\n"
-    "  \"# NOSORT\" immediately preceeding the assignment. e.g.\n"
-    "\n"
-    "  # NOSORT\n"
-    "  sources = [\n"
-    "    \"z.cc\",\n"
-    "    \"a.cc\",\n"
-    "  ]\n"
-    "\n"
-    "Arguments\n"
-    "\n"
-    "  --dry-run\n"
-    "      Does not change or output anything, but sets the process exit code\n"
-    "      based on whether output would be different than what's on disk.\n"
-    "      This is useful for presubmit/lint-type checks.\n"
-    "      - Exit code 0: successful format, matches on disk.\n"
-    "      - Exit code 1: general failure (parse error, etc.)\n"
-    "      - Exit code 2: successful format, but differs from on disk.\n"
-    "\n"
-    "  --dump-tree\n"
-    "      For debugging, dumps the parse tree to stdout and does not update\n"
-    "      the file or print formatted output.\n"
-    "\n"
-    "  --stdin\n"
-    "      Read input from stdin and write to stdout rather than update\n"
-    "      a file in-place.\n"
-    "\n"
-    "Examples\n"
-    "  gn format //some/BUILD.gn\n"
-    "  gn format some\\BUILD.gn\n"
-    "  gn format /abspath/some/BUILD.gn\n"
-    "  gn format --stdin\n";
+    R"(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 preceeding 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
+)";
 
 namespace {
 
diff --git a/tools/gn/command_gen.cc b/tools/gn/command_gen.cc
index fa5b75a..aac61e7 100644
--- a/tools/gn/command_gen.cc
+++ b/tools/gn/command_gen.cc
@@ -271,106 +271,102 @@
 const char kGen[] = "gen";
 const char kGen_HelpShort[] = "gen: Generate ninja files.";
 const char kGen_Help[] =
-    "gn gen: Generate ninja files.\n"
-    "\n"
-    "  gn gen [<ide options>] <out_dir>\n"
-    "\n"
-    "  Generates ninja files from the current tree and puts them in the given\n"
-    "  output directory.\n"
-    "\n"
-    "  The output directory can be a source-repo-absolute path name such as:\n"
-    "      //out/foo\n"
-    "  Or it can be a directory relative to the current directory such as:\n"
-    "      out/foo\n"
-    "\n"
-    "  See \"gn help switches\" for the common command-line switches.\n"
-    "\n"
-    "IDE options\n"
-    "\n"
-    "  GN optionally generates files for IDE. Possibilities for <ide options>\n"
-    "\n"
-    "  --ide=<ide_name>\n"
-    "      Generate files for an IDE. Currently supported values:\n"
-    "      \"eclipse\" - Eclipse CDT settings file.\n"
-    "      \"vs\" - Visual Studio project/solution files.\n"
-    "             (default Visual Studio version: 2015)\n"
-    "      \"vs2013\" - Visual Studio 2013 project/solution files.\n"
-    "      \"vs2015\" - Visual Studio 2015 project/solution files.\n"
-    "      \"xcode\" - Xcode workspace/solution files.\n"
-    "      \"qtcreator\" - QtCreator project files.\n"
-    "      \"json\" - JSON file containing target information\n"
-    "\n"
-    "  --filters=<path_prefixes>\n"
-    "      Semicolon-separated list of label patterns used to limit the set\n"
-    "      of generated projects (see \"gn help label_pattern\"). Only\n"
-    "      matching targets and their dependencies will be included in the\n"
-    "      solution. Only used for Visual Studio, Xcode and JSON.\n"
-    "\n"
-    "Visual Studio Flags\n"
-    "\n"
-    "  --sln=<file_name>\n"
-    "      Override default sln file name (\"all\"). Solution file is written\n"
-    "      to the root build directory.\n"
-    "\n"
-    "  --no-deps\n"
-    "      Don't include targets dependencies to the solution. Changes the\n"
-    "      way how --filters option works. Only directly matching targets are\n"
-    "      included.\n"
-    "\n"
-    "Xcode Flags\n"
-    "\n"
-    "  --workspace=<file_name>\n"
-    "      Override defaut workspace file name (\"all\"). The workspace file\n"
-    "      is written to the root build directory.\n"
-    "\n"
-    "  --ninja-extra-args=<string>\n"
-    "      This string is passed without any quoting to the ninja invocation\n"
-    "      command-line. Can be used to configure ninja flags, like \"-j\" if\n"
-    "      using goma for example.\n"
-    "\n"
-    "  --root-target=<target_name>\n"
-    "      Name of the target corresponding to \"All\" target in Xcode.\n"
-    "      If unset, \"All\" invokes ninja without any target\n"
-    "      and builds everything.\n"
-    "\n"
-    "QtCreator Flags\n"
-    "\n"
-    "  --root-target=<target_name>\n"
-    "      Name of the root target for which the QtCreator project will be\n"
-    "      generated to contain files of it and its dependencies. If unset, \n"
-    "      the whole build graph will be emitted.\n"
-    "\n"
-    "\n"
-    "Eclipse IDE Support\n"
-    "\n"
-    "  GN DOES NOT generate Eclipse CDT projects. Instead, it generates a\n"
-    "  settings file which can be imported into an Eclipse CDT project. The\n"
-    "  XML file contains a list of include paths and defines. Because GN does\n"
-    "  not generate a full .cproject definition, it is not possible to\n"
-    "  properly define includes/defines for each file individually.\n"
-    "  Instead, one set of includes/defines is generated for the entire\n"
-    "  project. This works fairly well but may still result in a few indexer\n"
-    "  issues here and there.\n"
-    "\n"
-    "Generic JSON Output\n"
-    "\n"
-    "  Dumps target information to JSON file and optionally invokes python\n"
-    "  script on generated file.\n"
-    "  See comments at the beginning of json_project_writer.cc and\n"
-    "  desc_builder.cc for overview of JSON file format.\n"
-    "\n"
-    "  --json-file-name=<json_file_name>\n"
-    "      Overrides default file name (project.json) of generated JSON file.\n"
-    "\n"
-    "  --json-ide-script=<path_to_python_script>\n"
-    "      Executes python script after the JSON file is generated.\n"
-    "      Path can be project absolute (//), system absolute (/) or\n"
-    "      relative, in which case the output directory will be base.\n"
-    "      Path to generated JSON file will be first argument when invoking\n"
-    "      script.\n"
-    "\n"
-    "  --json-ide-script-args=<argument>\n"
-    "      Optional second argument that will passed to executed script.\n";
+    R"(gn gen: Generate ninja files.
+
+  gn gen [<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
+
+  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: 2015)
+      "vs2013" - Visual Studio 2013 project/solution files.
+      "vs2015" - Visual Studio 2015 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.
+
+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" if using
+      goma for example.
+
+  --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 JSON file and optionally invokes python script on
+  generated file. See comments at the beginning of json_project_writer.cc and
+  desc_builder.cc for overview of 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.
+)";
 
 int RunGen(const std::vector<std::string>& args) {
   base::ElapsedTimer timer;
diff --git a/tools/gn/command_help.cc b/tools/gn/command_help.cc
index 68f0d04..b8e17e0 100644
--- a/tools/gn/command_help.cc
+++ b/tools/gn/command_help.cc
@@ -152,22 +152,23 @@
 const char kHelp_HelpShort[] =
     "help: Does what you think.";
 const char kHelp_Help[] =
-    "gn help <anything>\n"
-    "\n"
-    "  Yo dawg, I heard you like help on your help so I put help on the help\n"
-    "  in the help.\n"
-    "\n"
-    "  You can also use \"all\" as the parameter to get all help at once.\n"
-    "\n"
-    "Switches\n"
-    "\n"
-    "  --markdown\n"
-    "      Format output in markdown syntax.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  gn help --markdown all\n"
-    "      Dump all help to stdout in markdown format.\n";
+    R"(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.
+)";
 
 int RunHelp(const std::vector<std::string>& args) {
   std::string what;
diff --git a/tools/gn/command_ls.cc b/tools/gn/command_ls.cc
index 4d14e0f..676ff57 100644
--- a/tools/gn/command_ls.cc
+++ b/tools/gn/command_ls.cc
@@ -19,51 +19,52 @@
 const char kLs_HelpShort[] =
     "ls: List matching targets.";
 const char kLs_Help[] =
-    "gn ls <out_dir> [<label_pattern>] [--all-toolchains] [--as=...]\n"
-    "      [--type=...] [--testonly=...]\n"
-    "\n"
-    "  Lists all targets matching the given pattern for the given build\n"
-    "  directory. By default, only targets in the default toolchain will\n"
-    "  be matched unless a toolchain is explicitly supplied.\n"
-    "\n"
-    "  If the label pattern is unspecified, list all targets. The label\n"
-    "  pattern is not a general regular expression (see\n"
-    "  \"gn help label_pattern\"). If you need more complex expressions,\n"
-    "  pipe the result through grep.\n"
-    "\n"
-    "Options\n"
-    "\n"
+    R"(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
+
+)"
     TARGET_PRINTING_MODE_COMMAND_LINE_HELP
-    "\n"
+"\n"
     ALL_TOOLCHAINS_SWITCH_HELP
-    "\n"
+"\n"
     TARGET_TESTONLY_FILTER_COMMAND_LINE_HELP
-    "\n"
+"\n"
     TARGET_TYPE_FILTER_COMMAND_LINE_HELP
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gn ls out/Debug\n"
-    "      Lists all targets in the default toolchain.\n"
-    "\n"
-    "  gn ls out/Debug \"//base/*\"\n"
-    "      Lists all targets in the directory base and all subdirectories.\n"
-    "\n"
-    "  gn ls out/Debug \"//base:*\"\n"
-    "      Lists all targets defined in //base/BUILD.gn.\n"
-    "\n"
-    "  gn ls out/Debug //base --as=output\n"
-    "      Lists the build output file for //base:base\n"
-    "\n"
-    "  gn ls out/Debug --type=executable\n"
-    "      Lists all executables produced by the build.\n"
-    "\n"
-    "  gn ls out/Debug \"//base/*\" --as=output | xargs ninja -C out/Debug\n"
-    "      Builds all targets in //base and all subdirectories.\n"
-    "\n"
-    "  gn ls out/Debug //base --all-toolchains\n"
-    "      Lists all variants of the target //base:base (it may be referenced\n"
-    "      in multiple toolchains).\n";
+R"(
+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).
+)";
 
 int RunLs(const std::vector<std::string>& args) {
   if (args.size() == 0) {
diff --git a/tools/gn/command_path.cc b/tools/gn/command_path.cc
index a17001d..f6a4e69 100644
--- a/tools/gn/command_path.cc
+++ b/tools/gn/command_path.cc
@@ -278,44 +278,44 @@
 const char kPath_HelpShort[] =
     "path: Find paths between two targets.";
 const char kPath_Help[] =
-    "gn path <out_dir> <target_one> <target_two>\n"
-    "\n"
-    "  Finds paths of dependencies between two targets. Each unique path\n"
-    "  will be printed in one group, and groups will be separate by newlines.\n"
-    "  The two targets can appear in either order (paths will be found going\n"
-    "  in either direction).\n"
-    "\n"
-    "  By default, a single path will be printed. If there is a path with\n"
-    "  only public dependencies, the shortest public path will be printed.\n"
-    "  Otherwise, the shortest path using either public or private\n"
-    "  dependencies will be printed. If --with-data is specified, data deps\n"
-    "  will also be considered. If there are multiple shortest paths, an\n"
-    "  arbitrary one will be selected.\n"
-    "\n"
-    "Interesting paths\n"
-    "\n"
-    "  In a large project, there can be 100's of millions of unique paths\n"
-    "  between a very high level and a common low-level target. To make the\n"
-    "  output more useful (and terminate in a reasonable time), GN will not\n"
-    "  revisit sub-paths previously known to lead to the target.\n"
-    "\n"
-    "Options\n"
-    "\n"
-    "  --all\n"
-    "     Prints all \"interesting\" paths found rather than just the first\n"
-    "     one. Public paths will be printed first in order of increasing\n"
-    "     length, followed by non-public paths in order of increasing length.\n"
-    "\n"
-    "  --public\n"
-    "     Considers only public paths. Can't be used with --with-data.\n"
-    "\n"
-    "  --with-data\n"
-    "     Additionally follows data deps. Without this flag, only public and\n"
-    "     private linked deps will be followed. Can't be used with --public.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  gn path out/Default //base //tools/gn\n";
+    R"(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
+)";
 
 int RunPath(const std::vector<std::string>& args) {
   if (args.size() != 3) {
diff --git a/tools/gn/command_refs.cc b/tools/gn/command_refs.cc
index 184f901..6fa0146 100644
--- a/tools/gn/command_refs.cc
+++ b/tools/gn/command_refs.cc
@@ -285,105 +285,109 @@
 const char kRefs_HelpShort[] =
     "refs: Find stuff referencing a target or file.";
 const char kRefs_Help[] =
-    "gn refs <out_dir> (<label_pattern>|<label>|<file>|@<response_file>)* "
-    "[--all]\n"
-    "        [--all-toolchains] [--as=...] [--testonly=...] [--type=...]\n"
-    "\n"
-    "  Finds reverse dependencies (which targets reference something). The\n"
-    "  input is a list containing:\n"
-    "\n"
-    "   - Target label: The result will be which targets depend on it.\n"
-    "\n"
-    "   - Config label: The result will be which targets list the given\n"
-    "     config in its \"configs\" or \"public_configs\" list.\n"
-    "\n"
-    "   - Label pattern: The result will be which targets depend on any\n"
-    "     target matching the given pattern. Patterns will not match\n"
-    "     configs. These are not general regular expressions, see\n"
-    "     \"gn help label_pattern\" for details.\n"
-    "\n"
-    "   - File name: The result will be which targets list the given file in\n"
-    "     its \"inputs\", \"sources\", \"public\", \"data\", or \"outputs\".\n"
-    "     Any input that does not contain wildcards and does not match a\n"
-    "     target or a config will be treated as a file.\n"
-    "\n"
-    "   - Response file: If the input starts with an \"@\", it will be\n"
-    "     interpreted as a path to a file containing a list of labels or\n"
-    "     file names, one per line. This allows us to handle long lists\n"
-    "     of inputs without worrying about command line limits.\n"
-    "\n"
-    "Options\n"
-    "\n"
-    "  --all\n"
-    "      When used without --tree, will recurse and display all unique\n"
-    "      dependencies of the given targets. For example, if the input is\n"
-    "      a target, this will output all targets that depend directly or\n"
-    "      indirectly on the input. If the input is a file, this will output\n"
-    "      all targets that depend directly or indirectly on that file.\n"
-    "\n"
-    "      When used with --tree, turns off eliding to show a complete tree.\n"
-    "\n"
-    ALL_TOOLCHAINS_SWITCH_HELP
-    "\n"
-    TARGET_PRINTING_MODE_COMMAND_LINE_HELP
-    "\n"
-    "  -q\n"
-    "     Quiet. If nothing matches, don't print any output. Without this\n"
-    "     option, if there are no matches there will be an informational\n"
-    "     message printed which might interfere with scripts processing the\n"
-    "     output.\n"
-    "\n"
-    TARGET_TESTONLY_FILTER_COMMAND_LINE_HELP
-    "\n"
-    "  --tree\n"
-    "      Outputs a reverse dependency tree from the given target.\n"
-    "      Duplicates will be elided. Combine with --all to see a full\n"
-    "      dependency tree.\n"
-    "\n"
-    "      Tree output can not be used with the filtering or output flags:\n"
-    "      --as, --type, --testonly.\n"
-    "\n"
-    TARGET_TYPE_FILTER_COMMAND_LINE_HELP
-    "\n"
-    "Examples (target input)\n"
-    "\n"
-    "  gn refs out/Debug //tools/gn:gn\n"
-    "      Find all targets depending on the given exact target name.\n"
-    "\n"
-    "  gn refs out/Debug //base:i18n --as=buildfiles | xargs gvim\n"
-    "      Edit all .gn files containing references to //base:i18n\n"
-    "\n"
-    "  gn refs out/Debug //base --all\n"
-    "      List all targets depending directly or indirectly on //base:base.\n"
-    "\n"
-    "  gn refs out/Debug \"//base/*\"\n"
-    "      List all targets depending directly on any target in //base or\n"
-    "      its subdirectories.\n"
-    "\n"
-    "  gn refs out/Debug \"//base:*\"\n"
-    "      List all targets depending directly on any target in\n"
-    "      //base/BUILD.gn.\n"
-    "\n"
-    "  gn refs out/Debug //base --tree\n"
-    "      Print a reverse dependency tree of //base:base\n"
-    "\n"
-    "Examples (file input)\n"
-    "\n"
-    "  gn refs out/Debug //base/macros.h\n"
-    "      Print target(s) listing //base/macros.h as a source.\n"
-    "\n"
-    "  gn refs out/Debug //base/macros.h --tree\n"
-    "      Display a reverse dependency tree to get to the given file. This\n"
-    "      will show how dependencies will reference that file.\n"
-    "\n"
-    "  gn refs out/Debug //base/macros.h //base/at_exit.h --all\n"
-    "      Display all unique targets with some dependency path to a target\n"
-    "      containing either of the given files as a source.\n"
-    "\n"
-    "  gn refs out/Debug //base/macros.h --testonly=true --type=executable\n"
-    "          --all --as=output\n"
-    "      Display the executable file names of all test executables\n"
-    "      potentially affected by a change to the given file.\n";
+    R"(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_SWITCH_HELP
+"\n"
+TARGET_PRINTING_MODE_COMMAND_LINE_HELP
+
+R"(
+  -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.
+)"
+
+TARGET_TESTONLY_FILTER_COMMAND_LINE_HELP
+
+R"(
+  --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.
+)"
+
+TARGET_TYPE_FILTER_COMMAND_LINE_HELP
+
+R"(
+
+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.
+)";
 
 int RunRefs(const std::vector<std::string>& args) {
   if (args.size() <= 1) {
diff --git a/tools/gn/docs/reference.md b/tools/gn/docs/reference.md
index 356712f..4cc5f12 100644
--- a/tools/gn/docs/reference.md
+++ b/tools/gn/docs/reference.md
@@ -7,10 +7,10 @@
 ```
   See "gn help buildargs" for an overview of how build arguments work.
 
-  Most operations take a build directory. The build arguments are taken
-  from the previous build done in that directory. If a command specifies
-  --args, it will override the previous arguments stored in the build
-  directory, and use the specified ones.
+  Most operations take a build directory. The build arguments are taken from
+  the previous build done in that directory. If a command specifies --args, it
+  will override the previous arguments stored in the build directory, and use
+  the specified ones.
 
   The args specified will be saved to the build directory for subsequent
   commands. Specifying --args="" will clear all build arguments.
@@ -20,9 +20,8 @@
 ### **Formatting**
 
 ```
-  The value of the switch is interpreted in GN syntax. For typical usage
-  of string arguments, you will need to be careful about escaping of
-  quotes.
+  The value of the switch is interpreted in GN syntax. For typical usage of
+  string arguments, you will need to be careful about escaping of quotes.
 
 ```
 
@@ -38,7 +37,6 @@
 
   gn desc out/Default --args="some_list=[1, false, \"foo\"]"
 
-
 ```
 ## **\--[no]color**: Forces colored output on or off.
 
@@ -68,28 +66,26 @@
   Note that this interacts with "--root" in a possibly incorrect way.
   It would be nice to test the edge cases and document or fix.
 
-
 ```
 ## **\--fail-on-unused-args**: Treat unused build args as fatal errors.
 
 ```
-  If you set a value in a build's "gn args" and never use it in the
-  build (in a declare_args() block), GN will normally print an error
-  but not fail the build.
+  If you set a value in a build's "gn args" and never use it in the build (in
+  a declare_args() block), GN will normally print an error but not fail the
+  build.
 
-  In many cases engineers would use build args to enable or disable
-  features that would sometimes get removed. It would by annoying to
-  block work for typically benign problems. In Chrome in particular,
-  flags might be configured for build bots in a separate infrastructure
-  repository, or a declare_args block might be changed in a third party
-  repository. Treating these errors as blocking forced complex multi-
-  way patches to land what would otherwise be simple changes.
+  In many cases engineers would use build args to enable or disable features
+  that would sometimes get removed. It would by annoying to block work for
+  typically benign problems. In Chrome in particular, flags might be configured
+  for build bots in a separate infrastructure repository, or a declare_args
+  block might be changed in a third party repository. Treating these errors as
+  blocking forced complex multi- way patches to land what would otherwise be
+  simple changes.
 
-  In some cases, such concerns are not as important, and a mismatch
-  in build flags between the invoker of the build and the build files
-  represents a critical mismatch that should be immediately fixed. Such
-  users can set this flag to force GN to fail in that case.
-
+  In some cases, such concerns are not as important, and a mismatch in build
+  flags between the invoker of the build and the build files represents a
+  critical mismatch that should be immediately fixed. Such users can set this
+  flag to force GN to fail in that case.
 
 ```
 ## **\--markdown**: Write help output in the Markdown format.
@@ -117,18 +113,17 @@
 ```
   This is useful when running as a part of another script.
 
-
 ```
 ## **\--root**: Explicitly specify source root.
 
 ```
-  Normally GN will look up in the directory tree from the current
-  directory to find a ".gn" file. The source root directory specifies
-  the meaning of "//" beginning with paths, and the BUILD.gn file
-  in that directory will be the first thing loaded.
+  Normally GN will look up in the directory tree from the current directory to
+  find a ".gn" file. The source root directory specifies the meaning of "//"
+  beginning with paths, and the BUILD.gn file in that directory will be the
+  first thing loaded.
 
-  Specifying --root allows GN to do builds in a specific directory
-  regardless of the current directory.
+  Specifying --root allows GN to do builds in a specific directory regardless
+  of the current directory.
 
 ```
 
@@ -139,62 +134,58 @@
 
   gn desc //out/Default --root="C:\Users\BObama\My Documents\foo"
 
-
 ```
 ## **\--runtime-deps-list-file**: Save runtime dependencies for targets in file.
 
 ```
   --runtime-deps-list-file=<filename>
 
-  Where <filename> is a text file consisting of the labels, one per
-  line, of the targets for which runtime dependencies are desired.
+  Where <filename> is a text file consisting of the labels, one per line, of
+  the targets for which runtime dependencies are desired.
 
-  See "gn help runtime_deps" for a description of how runtime
-  dependencies are computed.
+  See "gn help runtime_deps" for a description of how runtime dependencies are
+  computed.
 
 ```
 
 ### **Runtime deps output file**
 
 ```
-  For each target requested, GN will write a separate runtime dependency
-  file. The runtime dependency file will be in the output directory
-  alongside the output file of the target, with a ".runtime_deps"
-  extension. For example, if the target "//foo:bar" is listed in the
-  input file, and that target produces an output file "bar.so", GN
-  will create a file "bar.so.runtime_deps" in the build directory.
+  For each target requested, GN will write a separate runtime dependency file.
+  The runtime dependency file will be in the output directory alongside the
+  output file of the target, with a ".runtime_deps" extension. For example, if
+  the target "//foo:bar" is listed in the input file, and that target produces
+  an output file "bar.so", GN will create a file "bar.so.runtime_deps" in the
+  build directory.
 
-  If a source set, action, copy, or group is listed, the runtime deps
-  file will correspond to the .stamp file corresponding to that target.
-  This is probably not useful; the use-case for this feature is
-  generally executable targets.
+  If a source set, action, copy, or group is listed, the runtime deps file will
+  correspond to the .stamp file corresponding to that target. This is probably
+  not useful; the use-case for this feature is generally executable targets.
 
-  The runtime dependency 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
-  (in the above example, "bar.so").
-
+  The runtime dependency 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 (in the above example,
+  "bar.so").
 
 ```
 ## **\--script-executable**: Set the executable used to execute scripts.
 
 ```
-  By default GN searches the PATH for Python to execute scripts in
-  action targets and exec_script calls. This flag allows the
-  specification of a specific Python executable or potentially
-  a different language interpreter.
-
+  By default GN searches the PATH for Python to execute scripts in action
+  targets and exec_script calls. This flag allows the specification of a
+  specific Python executable or potentially a different language
+  interpreter.
 
 ```
 ## **\--threads**: Specify number of worker threads.
 
 ```
-  GN runs many threads to load and run build files. This can make
-  debugging challenging. Or you may want to experiment with different
-  values to see how it affects performance.
+  GN runs many threads to load and run build files. This can make debugging
+  challenging. Or you may want to experiment with different values to see how
+  it affects performance.
 
-  The parameter is the number of worker threads. This does not count the
-  main thread (so there are always at least two).
+  The parameter is the number of worker threads. This does not count the main
+  thread (so there are always at least two).
 
 ```
 
@@ -203,7 +194,6 @@
 ```
   gen gen out/Default --threads=1
 
-
 ```
 ## **\--time**: Outputs a summary of how long everything took.
 
@@ -217,16 +207,15 @@
 ```
   gn gen out/Default --time
 
-
 ```
 ## **\--tracelog**: Writes a Chrome-compatible trace log to the given file.
 
 ```
-  The trace log will show file loads, executions, scripts, and writes.
-  This allows performance analysis of the generation step.
+  The trace log will show file loads, executions, scripts, and writes. This
+  allows performance analysis of the generation step.
 
-  To view the trace, open Chrome and navigate to "chrome://tracing/",
-  then press "Load" and specify the file you passed to this parameter.
+  To view the trace, open Chrome and navigate to "chrome://tracing/", then
+  press "Load" and specify the file you passed to this parameter.
 
 ```
 
@@ -235,14 +224,13 @@
 ```
   gn gen out/Default --tracelog=mytrace.trace
 
-
 ```
 ## **-v**: Verbose logging.
 
 ```
   This will spew logging events to the console for debugging issues.
-  Good luck!
 
+  Good luck!
 
 ```
 ## **gn analyze <out_dir> <input_path> <output_path>**
@@ -254,73 +242,66 @@
 
   out_dir is the path to the build directory.
 
-  input_path is a path to a file containing a JSON object with three
-  fields:
+  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.
+   - "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.
+   - "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.
+     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:
+  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.
+     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.
+   - "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".
+   - "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)"
+       - "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.
+     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.
+   - "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.
 
 ```
 ## **gn args <out_dir> [\--list] [\--short] [\--args]**
@@ -334,41 +315,41 @@
 ### **Usage**
 ```
   gn args <out_dir>
-      Open the arguments for the given build directory in an editor
-      (as specified by the EDITOR environment variable). 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:
+      Open the arguments for the given build directory in an editor (as
+      specified by the EDITOR environment variable). 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"
 
-      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>".
+      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]
-      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.
+      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, default value, and
-      comment preceeding the declaration. If --short is specified,
-      only the names and values will be printed.
+      The output will list the declaration location, default value, and comment
+      preceeding the declaration. If --short is specified, only the names and
+      values will be printed.
 
-      If the out_dir is specified, the build configuration will be
-      taken from that build directory. The reason this is needed is that
-      the definition of some arguments is dependent on the build
-      configuration, so setting some values might add, remove, or change
-      the default values for other arguments. Specifying your exact
-      configuration allows the proper arguments to be displayed.
+      If the out_dir is specified, the build configuration will be taken from
+      that build directory. The reason this is needed is that the definition of
+      some arguments is dependent on the build configuration, so setting some
+      values might add, remove, or change the default values for other
+      arguments. Specifying your exact configuration allows the proper
+      arguments to be displayed.
 
-      Instead of specifying the out_dir, you can also use the
-      command-line flag to specify the build configuration:
+      Instead of specifying the out_dir, you can also use the command-line flag
+      to specify the build configuration:
         --args=<exact list of args to use>
 
 ```
 
 ### **Examples**
+
 ```
   gn args out/Debug
     Opens an editor with the args for out/Debug.
@@ -378,7 +359,8 @@
     build.
 
   gn args out/Debug --list=target_cpu
-    Prints information about the "target_cpu" argument for the out/Debug
+    Prints information about the "target_cpu" argument for the "
+   "out/Debug
     build.
 
   gn args --list --args="os=\"android\" enable_doom_melon=true"
@@ -386,22 +368,20 @@
     given arguments set (which may affect the values of other
     arguments).
 
-
 ```
 ## **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'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.
+  "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.
+  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.
 
 ```
 
@@ -409,96 +389,92 @@
 
 ```
   --force
-      Ignores specifications of "check_includes = false" and checks
-      all target's files that match the target label.
+      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".
+  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").
+  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.
+    - 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.
+    - Only includes using "quotes" are checked. <brackets> are assumed to be
+      system includes.
 
-    - Include paths are assumed to be relative to either the source root
-      or the "root_gen_dir" and must include all the path components.
-      (It might be nice in the future to incorporate GN's knowledge of
-      the include path to handle other include styles.)
+    - Include paths are assumed to be relative to either the source root or the
+      "root_gen_dir" and must include all the path components. (It might be
+      nice in the future to incorporate GN's knowledge of the include path to
+      handle other include styles.)
 
-    - GN does not run the preprocessor so will not understand
-      conditional includes.
+    - 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.
+    - 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).
+    - 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.
+    - 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 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.
+    - 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.
 
-    - Ouptuts from actions are treated like public sources on that
-      target.
+    - Ouptuts 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".
+    - 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 uses relative includes,
-  it's generally best to exclude that target from checking altogether
-  via "check_includes = false".
+  If you have a third party project that uses relative includes, 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 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").
+  "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.
+  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.
+  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.
 
 ```
 
@@ -514,7 +490,6 @@
   gn check out/Default "//foo/*
       Check only the files in targets in the //foo directory tree.
 
-
 ```
 ## **gn clean <out_dir>**
 
@@ -524,15 +499,16 @@
 
 
 ```
-## **gn desc <out_dir> <label or pattern> [<what to show>] [\--blame] [\--format=json]**
+## **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>.
+  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.
+  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.
 
 ```
 
@@ -567,19 +543,17 @@
   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.
+      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.
+      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.
@@ -599,47 +573,42 @@
 
 ```
   --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).
+      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.
+  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.
+  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).
+  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:
+  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).
-
+      Collects all recursive dependencies and prints a sorted flat list. Also
+      usable with --tree (see below).
   --as=(buildfile|label|output)
       How to print targets.
 
@@ -658,31 +627,27 @@
       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.
+      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.
+      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.
-
+      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).
+  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).
 
 ```
 
@@ -700,16 +665,15 @@
       Shows defines set for the //base:base target, annotated by where
       each one was set from.
 
-
 ```
 ## **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 preceeding the assignment. e.g.
+  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 preceeding the assignment. e.g.
 
   # NOSORT
   sources = [
@@ -723,39 +687,38 @@
 
 ```
   --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.
+      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.
+      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.
+      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 some\\BUILD.gn
   gn format /abspath/some/BUILD.gn
   gn format --stdin
 
-
 ```
 ## **gn gen**: Generate ninja files.
 
 ```
   gn gen [<ide options>] <out_dir>
 
-  Generates ninja files from the current tree and puts them in the given
-  output directory.
+  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
@@ -783,10 +746,10 @@
       "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.
+      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.
 
 ```
 
@@ -794,13 +757,12 @@
 
 ```
   --sln=<file_name>
-      Override default sln file name ("all"). Solution file is written
-      to the root build directory.
+      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.
+      Don't include targets dependencies to the solution. Changes the way how
+      --filters option works. Only directly matching targets are included.
 
 ```
 
@@ -808,18 +770,17 @@
 
 ```
   --workspace=<file_name>
-      Override defaut workspace file name ("all"). The workspace file
-      is written to the root build directory.
+      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" if
-      using goma for example.
+      command-line. Can be used to configure ninja flags, like "-j" if using
+      goma for example.
 
   --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.
+      Name of the target corresponding to "All" target in Xcode. If unset,
+      "All" invokes ninja without any target and builds everything.
 
 ```
 
@@ -827,9 +788,9 @@
 
 ```
   --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.
+      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.
 
 
 ```
@@ -837,45 +798,41 @@
 ### **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.
+  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 JSON file and optionally invokes python
-  script on generated file.
-  See comments at the beginning of json_project_writer.cc and
+  Dumps target information to JSON file and optionally invokes python script on
+  generated file. See comments at the beginning of json_project_writer.cc and
   desc_builder.cc for overview of 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.
+      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.
 
-
 ```
 ## **gn help <anything>**
 
 ```
-  Yo dawg, I heard you like help on your help so I put help on the help
-  in the help.
+  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.
 
@@ -895,20 +852,18 @@
   gn help --markdown all
       Dump all help to stdout in markdown format.
 
-
 ```
 ## **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.
+  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.
+  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.
 
 ```
 
@@ -973,32 +928,30 @@
       Lists all variants of the target //base:base (it may be referenced
       in multiple toolchains).
 
-
 ```
 ## **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).
+  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.
+  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.
+  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.
 
 ```
 
@@ -1006,16 +959,16 @@
 
 ```
   --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.
+     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.
+     Additionally follows data deps. Without this flag, only public and private
+     linked deps will be followed. Can't be used with --public.
 
 ```
 
@@ -1024,34 +977,32 @@
 ```
   gn path out/Default //base //tools/gn
 
-
 ```
 ## **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:
+  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.
+   - 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.
+   - 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.
+   - 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.
+   - 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.
 
 ```
 
@@ -1060,13 +1011,12 @@
 ```
   --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.
+      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.
@@ -1089,29 +1039,26 @@
           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.
-
+     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.
+      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.
-
+      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)**
@@ -1158,39 +1105,37 @@
       Display the executable file names of all test executables
       potentially affected by a change to the given file.
 
-
 ```
 ## **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".
+  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.
+  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".
+  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".
+  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.
-
+  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
@@ -1203,9 +1148,8 @@
 ### **Outputs**
 
 ```
-  You should specify files created by your script by specifying them in
-  the "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
@@ -1216,7 +1160,6 @@
 ```
 
 ### **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
@@ -1242,48 +1185,44 @@
     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.
+    # 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.
+    # 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)
   }
 
-
 ```
 ## **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".
+  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.
+  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 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".
+  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".
-
+  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
@@ -1294,7 +1233,6 @@
 ```
 
 ### **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
@@ -1306,7 +1244,6 @@
 ```
 
 ### **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
@@ -1327,8 +1264,8 @@
 ### **Example**
 
 ```
-  # Runs the script over each IDL file. The IDL script will generate
-  # both a .cc and a .h file for each input.
+  # 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" ]
@@ -1341,9 +1278,9 @@
     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()".
+    # 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",
@@ -1351,8 +1288,6 @@
         "/{{source_name_part}}.h" ]
   }
 
-
-
 ```
 ## **assert**: Assert an expression is true at generation time.
 
@@ -1365,28 +1300,27 @@
 
 ```
 
-### **Examples**:
+### **Examples**
+
 ```
   assert(is_win)
-  assert(defined(sources), "Sources must be defined")
-
+  assert(defined(sources), "Sources must be defined");
 
 ```
 ## **bundle_data**: [iOS/OS X] 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.
+  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}}.
+  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/OS X bundle. In cross-platform projects, it is advised to
-  put it behind iOS/Mac conditionals.
+  generate iOS/OS X bundle. In cross-platform projects, it is advised to put it
+  behind iOS/Mac conditionals.
 
   See "gn help create_bundle" for more information.
 
@@ -1429,33 +1363,30 @@
     ]
   }
 
-
 ```
 ## **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.
+  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:
+  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.
+   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
+   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".
-   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, ldflags, lib_dirs, libs,
@@ -1483,27 +1414,24 @@
     configs = [ ":myconfig" ]
   }
 
-
 ```
 ## **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.
+  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).
+  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.
+  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.
 
 ```
 
@@ -1516,39 +1444,36 @@
     outputs = [ "$target_out_dir/mydll.dll" ]
   }
 
-  # Write a rule to copy several files to the target generated files
-  # directory.
+  # 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.
+    # 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}}" ]
   }
 
-
 ```
 ## **create_bundle**: [iOS/OS X] Build an OS X / iOS bundle.
 
 ```
   This target generates an iOS/OS X 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).
+  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.
+  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/OS X bundle. In cross-platform projects, it is advised to
-  put it behind iOS/Mac conditionals.
+  generate iOS/OS X bundle. In cross-platform projects, it is advised to put it
+  behind iOS/Mac 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.
+  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.
 
 ```
 
@@ -1556,17 +1481,17 @@
 
 ```
   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.
+  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 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
+  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.
 
 ```
@@ -1585,9 +1510,9 @@
 ### **Example**
 
 ```
-  # Defines a template to create an application. On most platform, this
-  # is just an alias for an "executable" target, but on iOS/OS X, it
-  # builds an application bundle.
+  # Defines a template to create an application. On most platform, this is just
+  # an alias for an "executable" target, but on iOS/OS X, it builds an
+  # application bundle.
   template("app") {
     if (!is_ios && !is_mac) {
       executable(target_name) {
@@ -1675,47 +1600,45 @@
     }
   }
 
-
 ```
 ## **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.
+  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_arg block executes. Any variables in the enclosing
-      scope are available for reading.
+   1. The declare_arg block executes. Any variables in the enclosing scope are
+      available for reading.
 
-   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.
+   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.
+   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.
+    - 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.
 
-    - Any code inside of the declare_args block will see the default
-      values of previous variables defined in the block rather than
-      the user-overridden value. This can be surprising because you will
-      be used to seeing the overridden value. If you need to make the
-      default value of one arg dependent on the possibly-overridden
-      value of another, write two separate declare_args blocks:
+    - Any code inside of the declare_args block will see the default values of
+      previous variables defined in the block rather than the user-overridden
+      value. This can be surprising because you will be used to seeing the
+      overridden value. If you need to make the default value of one arg
+      dependent on the possibly-overridden value of another, write two separate
+      declare_args blocks:
 
         declare_args() {
           enable_foo = true
@@ -1737,9 +1660,8 @@
 
   If you want to override the (default disabled) Doom Melon:
     gn --args="enable_doom_melon=true enable_teleporter=false"
-  This also sets the teleporter, but it's already defaulted to on so
-  it will have no effect.
-
+  This also sets the teleporter, but it's already defaulted to on so it will
+  have no effect.
 
 ```
 ## **defined**: Returns whether an identifier is defined.
@@ -1750,18 +1672,18 @@
 
   You can pass an identifier:
     defined(foo)
-  which will return true or false depending on whether foo is defined in
-  the current scope.
+  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.
+  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**:
+### **Example**
 
 ```
   template("mytemplate") {
@@ -1777,7 +1699,6 @@
     }
   }
 
-
 ```
 ## **exec_script**: Synchronously run a script and return the output.
 
@@ -1788,13 +1709,13 @@
               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.
+  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").
+  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").
 
 ```
 
@@ -1802,48 +1723,45 @@
 
 ```
   filename:
-      File name of python script to execute. Non-absolute names will
-      be treated as relative to the current build file.
+      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.
+      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".
+      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.
+      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.
+      (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.
+      The script itself will be an implicit dependency so you do not need to
+      list it.
 
 ```
 
-### **Example**:
+### **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.
+  # This example just calls the script with no arguments and discards the
+  # result.
   exec_script("//foo/bar/myscript.py")
 
-
 ```
 ## **executable**: Declare an executable target.
 
 ### **Variables**
-
 ```
   Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
          asmflags, defines, include_dirs, ldflags, lib_dirs, libs,
@@ -1858,21 +1776,21 @@
 ## **foreach**: Iterate over a list.
 
 ```
-  foreach(<loop_var>, <list>) {
-    <loop contents>
-  }
+    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.
+  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 block does not introduce a new scope, so that variable assignments
-  inside the loop will be visible once the loop terminates.
+  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.
+  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.
 
 ```
 
@@ -1889,7 +1807,6 @@
   b
   c
 
-
 ```
 ## **forward_variables_from**: Copies variables from a different scope.
 
@@ -1897,48 +1814,48 @@
   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.
+  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.
+  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.
+  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).
+  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.
+  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 "*".
+  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.
+  # 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" ])
+                                        "public_deps", "visibility" "
+                                                                    "])
       # Add our test code to the dependencies.
       # "deps" may or may not be defined at this point.
       if (defined(deps)) {
@@ -1949,15 +1866,15 @@
     }
   }
 
-  # This is a template around either a target whose type depends on a
-  # global variable. It forwards all values from the invoker.
+  # 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 
+  # 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) {
@@ -1969,17 +1886,15 @@
     }
   }
 
-
 ```
 ## **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.
+  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".
 
@@ -1990,48 +1905,42 @@
 ```
   "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".
+      "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".
+      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.
+      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
+      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.
+      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".
+      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)".
+      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.
+      "current_toolchain" variable when inside that target's declaration.
 
 ```
 
@@ -2044,17 +1953,15 @@
   get_label_info("//foo/bar:baz", "gen_dir")
   # Returns string "//out/Debug/gen/foo/bar".
 
-
 ```
 ## **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.
+  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.
 
 ```
 
@@ -2062,9 +1969,9 @@
 
 ```
   "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.
+      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/" => ""
@@ -2077,8 +1984,8 @@
         "foo/" => ""
 
   "extension"
-      The substring following the last period following the last slash,
-      or the empty string if not found. The period is not included.
+      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" => ""
 
@@ -2088,33 +1995,32 @@
         "//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.
+      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.
+      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.
+      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.
+      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().
+      If you want to make the path relative to another directory, or to be
+      system-absolute, see rebase_path().
 
 ```
 
@@ -2128,8 +2034,7 @@
   # result will be "//foo/bar"
 
   # Extract the source-absolute directory name,
-  result = get_path_info(get_path_info(path, "dir"), "abspath")
-
+  result = get_path_info(get_path_info(path, "dir"), "abspath"
 
 ```
 ## **get_target_outputs**: [file list] Get the list of outputs from a target.
@@ -2137,43 +2042,43 @@
 ```
   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).
+  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.
+  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).
+  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 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").
+  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.
+  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.
+  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.
 
 ```
 
@@ -2191,45 +2096,39 @@
     sources = get_target_outputs(":my_action")
   }
 
-
 ```
 ## **getenv**: Get an environment variable.
 
 ```
   value = getenv(env_var_name)
 
-  Returns the value of the given enironment 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.
+  Returns the value of the given enironment 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.
+  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**:
+### **Example**
 
 ```
   home_dir = getenv("HOME")
 
-
 ```
 ## **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.
-
-  Depending on a group is exactly like depending directly on that
-  group's deps. 
+  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
@@ -2246,38 +2145,36 @@
     ]
   }
 
-
 ```
 ## **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.
+  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.
+  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.
+  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.
+  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.
+  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**:
+### **Examples**
 
 ```
   import("//build/rules/idl_compilation_rule.gni")
@@ -2285,23 +2182,21 @@
   # Looks in the current directory.
   import("my_vars.gni")
 
-
 ```
 ## **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.
+  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.
+  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, ldflags, lib_dirs, libs,
@@ -2352,7 +2247,6 @@
     }
   }
 
-
 ```
 ## **print**: Prints to the console.
 
@@ -2360,21 +2254,21 @@
   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
+  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**:
+### **Examples**
+
 ```
   print("Hello world")
 
   print(sources, deps)
 
-
 ```
 ## **process_file_template**: Do template expansion over a list of files.
 
@@ -2385,27 +2279,27 @@
   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).
+  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**:
+### **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 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".
+  The template should contain source expansions to which each name in the
+  source list is applied. See "gn help source_expansion".
 
 ```
 
-### **Example**:
+### **Example**
 
 ```
   sources = [
@@ -2423,35 +2317,33 @@
       "//out/Debug/bar.cc"
       "//out/Debug/bar.h" ]
 
-
 ```
 ## **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.
+  Whitespace will be trimmed from the end of the file. Throws an error if the
+  file can not be opened.
 
 ```
 
-### **Arguments**:
+### **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".
+      Controls how the file is read and parsed. See "gn help input_conversion".
 
 ```
 
 ### **Example**
+
 ```
   lines = read_file("foo.txt", "list lines")
 
-
 ```
 ## **rebase_path**: Rebase a file or directory to another location.
 
@@ -2460,27 +2352,24 @@
                           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.
+  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.
+  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).
+  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.
+  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.
 
 ```
 
@@ -2488,42 +2377,40 @@
 
 ```
   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").
+      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).
+      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.
+      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.
+      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.
+  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 ("//.").
+  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 ("//.").
 
 ```
 
@@ -2537,14 +2424,14 @@
 
   # Convert a file to be system absolute:
   foo = rebase_path("myfile.txt")
-  # Might produce "D:\source\project\myfile.txt" on Windows or
+  # 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.
+    # 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
@@ -2557,31 +2444,30 @@
     ] + rebase_path(sources, root_build_dir)
   }
 
-
 ```
 ## **set_default_toolchain**: Sets the default toolchain name.
 
 ```
   set_default_toolchain(toolchain_label)
 
-  The given label should identify a toolchain definition (see
-  "help toolchain"). This toolchain will be used for all targets
-  unless otherwise specified.
+  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.
+  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.
+  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**:
+### **Argument**
 
 ```
   toolchain_label
@@ -2589,7 +2475,7 @@
 
 ```
 
-### **Example**:
+### **Example**
 
 ```
   set_default_toolchain("//build/config/win:vs32")
@@ -2600,21 +2486,20 @@
 ```
   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.
+  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.
+  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.
+  "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.
 
 ```
 
@@ -2628,51 +2513,48 @@
   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"
+    configs -= [ "//tools/mything:settings" ]
   }
 
-
 ```
 ## **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.
+  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.
+  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.
+  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
+  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.
+  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 ".*").
+   - "*" 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.
+   - "\b" Matches a path boundary. This will match the beginning or end of a
+     string, or a slash.
 
 ```
 
@@ -2702,21 +2584,19 @@
   print(sources)
   # Will print [ "a.cc" ]. b_win one was filtered out.
 
-
 ```
 ## **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.
+  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, ldflags, lib_dirs, libs,
@@ -2731,33 +2611,30 @@
 ## **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.
+  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.
+  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.
+  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.
+  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, ldflags, lib_dirs, libs,
@@ -2775,12 +2652,11 @@
   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.
+  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.
+  The expected use is to divide source files into smaller uniform chunks.
 
 ```
 
@@ -2794,23 +2670,22 @@
   Will print:
     [[1, 2], [3, 4], [5, 6]
 
-
 ```
 ## **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.
+  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**
 ```
+  complete_static_lib
   Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
          asmflags, defines, include_dirs, ldflags, lib_dirs, libs,
          precompiled_header, precompiled_source
@@ -2826,13 +2701,13 @@
 ```
   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.
+  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.
+  target_type_string parameter. Arbitrary functions, configs, and toolchains
+  are not supported.
 
   The call:
     target("source_set", "doom_melon") {
@@ -2854,93 +2729,90 @@
     ...
   }
 
-
 ```
 ## **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.
+  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.
+  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.
+  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 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.
+  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.
+  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:
+  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:
+  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**:
+### **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:
+  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.
+  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 globally unique names, or you will get collisions.
+  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.
+  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.
+  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.
 
 ```
 
-### **Example of defining a template**:
+### **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
+    # 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.
@@ -2952,22 +2824,20 @@
     # 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).
+    # 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.
+      # 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.
+      # 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.
@@ -2976,28 +2846,27 @@
                   "$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.
+    # 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.
+      # 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.
+      # This target depends on the files produced by the above code gen target.
       deps = [ ":$code_gen_target_name" ]
     }
   }
 
 ```
 
-### **Example of invoking the resulting template**:
+### **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.
+  # "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" ]
@@ -3005,18 +2874,17 @@
 
   # 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.
+    # 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" ]
   }
 
-
 ```
 ## **tool**: Specify arguments to a toolchain tool.
 
-### **Usage**:
+### **Usage**
 
 ```
   tool(<tool type>) {
@@ -3063,47 +2931,45 @@
         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.
+        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.
+        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.
+        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.
+        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".
+        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.
+        Format for the deps outputs. This is either "gcc" or "msvc". See the
+        ninja documentation for "deps" for more information.
 
         Example: depsformat = "gcc"
 
@@ -3118,29 +2984,28 @@
     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:
+        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".
+        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).
+        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.
+        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
+        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:
@@ -3148,19 +3013,19 @@
             "{{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.
+        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}}"
+                "{{output_extension}}",
             "{{output_dir}}/{{target_output_name}}.lib",
           ]
 
     pool [label, 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.
+        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".
 
@@ -3168,27 +3033,25 @@
     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.
+        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.
+        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.
+        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
@@ -3202,29 +3065,29 @@
         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".
+        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.
+        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.
+        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.
+        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
@@ -3238,12 +3101,12 @@
     rspfile_content  [string with substitutions]
         Valid for: all tools (required when "rspfile" is specified)
 
-        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.
+        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:
+        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"
@@ -3253,57 +3116,52 @@
     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.
+        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:
+  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.
+        "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.
+        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"
+        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"
+        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".
+        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}}.
 
-  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:
+        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}}
@@ -3317,47 +3175,45 @@
         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).
+        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).
+        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.
+        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"
+        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:
+  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.
+        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.
+        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
@@ -3365,68 +3221,68 @@
         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_prefix".
+        Expands to the list of system libraries to link to. Each will be
+        prefixed by the "lib_prefix".
 
         As a special case to support Mac, libraries with names ending in
-        ".framework" will be added to the {{libs}} with "-framework"
-        preceeding it, and the lib prefix will be ignored.
+        ".framework" will be added to the {{libs}} with "-framework" preceeding
+        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.
+        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.
+        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.
+        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 dependencide 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").
+        Extra libraries from shared library dependencide 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 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.
+  {{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/OS X bundles
-  and need only be defined on those platforms.
+  The copy_bundle_data and compile_xcassets tools only allows the common tool
+  substitutions. Both tools are required to create iOS/OS X 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 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 avaiable:
+  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 avaiable:
 
     {{inputs}}
-        Expands to the list of .xcassets to use as input to compile the
-        asset catalog.
+        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
@@ -3438,32 +3294,34 @@
 ### **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.
+  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.
+  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):
+  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",
+        "{{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"
+        "{{output_dir}}/{{target_output_name}}"
+            "{{output_extension}}.TOC"
       restat = true
     }
 
@@ -3487,16 +3345,14 @@
       outputs = [ "{{source_out_dir}}/{{source_name_part}}.o" ]
       description = "G++ {{source}}"
     }
-  }
-
+  };
 
 ```
 ## **toolchain**: Defines a toolchain.
 
 ```
-  A toolchain is a set of commands and build flags used to compile the
-  source code. You can have more than one toolchain in use at once in
-  a build.
+  A toolchain is a set of commands and build flags used to compile the source
+  code. You can have more than one toolchain in use at once in a build.
 
 ```
 
@@ -3504,66 +3360,62 @@
 
 ```
   tool()
-    The tool() function call specifies the commands commands to run for
-    a given step. See "gn help 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.
+    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.
+    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.
+    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.
+    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.
+    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:
+    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.
+    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.
 
 ```
 
-### **Invoking targets in toolchains**:
+### **Invoking targets in toolchains**
 
 ```
-  By default, when a target depends on another, there is an implicit
-  toolchain label that is inherited, so the dependee has the same one
-  as the dependent.
+  By default, when a target depends on another, there is an implicit toolchain
+  label that is inherited, so the dependee has the same one as the dependent.
 
   You can override this and refer to any other toolchain by explicitly
   labeling the toolchain to use. For example:
     data_deps = [ "//plugins:mine(//toolchains:plugin_toolchain)" ]
-  The string "//build/toolchains:plugin_toolchain" is a label that
-  identifies the toolchain declaration for compiling the sources.
+  The string "//build/toolchains:plugin_toolchain" is a label that identifies
+  the toolchain declaration for compiling the sources.
 
   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.
+   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.
 
 ```
 
@@ -3581,8 +3433,7 @@
       is_32bit = true
       is_64bit = false
     }
-  }
-
+  };
 
 ```
 ## **write_file**: Write a file to disk.
@@ -3590,20 +3441,19 @@
 ```
   write_file(filename, data)
 
-  If data is a list, the list will be written one-item-per-line with no
-  quoting or brackets.
+  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.
+  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
-  preferrable to use response files for this purpose. See
-  "gn help response_file_contents".
+  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 preferrable 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.
+  TODO(brettw) we probably need an optional third argument to control list
+  formatting.
 
 ```
 
@@ -3613,48 +3463,45 @@
   filename
       Filename to write. This must be within the output directory.
 
-  data:
+  data
       The list or string to write.
 
-
 ```
 ## **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.
+  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.
+  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.
 
-
 ```
 ## **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.
+  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.
+  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.
 
-
 ```
 ## **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
+  A fully-qualified label representing the current toolchain. You can use this
+  to make toolchain-related decisions in the build. See also
   "default_toolchain".
 
 ```
@@ -3666,69 +3513,66 @@
     executable("output_thats_64_bit_only") {
       ...
 
-
 ```
 ## **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 fully-qualified label representing the default toolchain, which may not
+  necessarily be the current one (see "current_toolchain").
 
 ```
 ## **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.
+  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.
+  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**:
+### **Some possible values**
+
 ```
   - "x64"
   - "x86"
 
-
 ```
 ## **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 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.
+  This value should generally be treated as read-only. It, however, is not used
+  internally by GN for any purpose.
 
 ```
 
-### **Some possible values**:
+### **Some possible values**
+
 ```
   - "linux"
   - "mac"
   - "win"
 
-
 ```
 ## **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.
+  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.
+  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.
+  This is often used with "defined" to see if a value is set on the invoking
+  scope.
 
   See "gn help template" for more examples.
 
@@ -3748,44 +3592,39 @@
     bar = 123
   }
 
-
 ```
 ## **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.
-
+  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.
 
 ```
 ## **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.
+  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.
-
+  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.
 
 ```
 ## **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.
+  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.
+  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.
-
+  See also "target_gen_dir" which is usually a better location for generated
+  files. It will be inside the root generated dir.
 
 ```
 ## **root_out_dir**: [string] Root directory for toolchain output files.
@@ -3794,17 +3633,16 @@
   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
+  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.
+  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.
+  See also "target_out_dir" which is usually a better location for output
+  files. It will be inside the root output dir.
 
 ```
 
@@ -3816,33 +3654,30 @@
     args = [ "-o", rebase_path(root_out_dir, root_build_dir) ]
   }
 
-
 ```
 ## **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.
+  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.
+  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.
-
-  Where practical, use one of the following list of common values:
+  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**:
+### **Possible values**
+
 ```
   - "x86"
   - "x64"
@@ -3850,21 +3685,19 @@
   - "arm64"
   - "mipsel"
 
-
 ```
 ## **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.
+  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.
+  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".
 
@@ -3875,29 +3708,27 @@
 ```
   action("myscript") {
     # Pass the generated output dir to the script.
-    args = [ "-o", rebase_path(target_gen_dir, root_build_dir) ]
+    args = [ "-o", rebase_path(target_gen_dir, root_build_dir) ]"
   }
 
-
 ```
 ## **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.
+  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.
+  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.
+  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.
 
@@ -3921,24 +3752,23 @@
   my_template("space_ray") {
   }
 
-
 ```
 ## **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.
+  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.
+  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
+  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") {
           # ...
@@ -3946,18 +3776,16 @@
 
   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.
-
-  Where practical, use one of the following list of common values:
+  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**:
+### **Possible values**
+
 ```
   - "android"
   - "chromeos"
@@ -3967,20 +3795,18 @@
   - "mac"
   - "win"
 
-
 ```
 ## **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.
+  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.
+  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".
 
@@ -3991,9 +3817,9 @@
 ```
   action("myscript") {
     # Pass the output dir to the script.
-    args = [ "-o", rebase_path(target_out_dir, root_build_dir) ]
-  }
+    args = [ "-o", rebase_path(target_out_dir, root_build_dir) ]"
 
+  }
 
 ```
 ## **all_dependent_configs**: Configs to be forced on dependents.
@@ -4001,16 +3827,16 @@
 ```
   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.
+  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 then 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.
+  dependencies have been resolved. Therefore, a target will not see these
+  force-added configs in their "configs" variable while the script is running,
+  and then 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".
 
@@ -4038,61 +3864,57 @@
 ## **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.
+  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.
+  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").
+  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.
+  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.
+  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.
+  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.
+  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).
+  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).
 
 ```
 
@@ -4115,7 +3937,6 @@
     public_deps = [ ":c" ]
   }
 
-
 ```
 ## **arflags**: Arguments passed to static_library archiver.
 
@@ -4123,14 +3944,14 @@
   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.
+  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.
 
 ```
 
@@ -4156,21 +3977,20 @@
 ## **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.
+  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".
 
-
 ```
 ## **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.
+  "asmflags" are passed to any invocation of a tool that takes an .asm or .S
+  file as input.
 
 ```
 
@@ -4198,29 +4018,27 @@
 ```
   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.
+  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).
+  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.
+  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.
+  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.
 
 ```
 
@@ -4236,20 +4054,19 @@
     ]
   }
 
-
 ```
 ## **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 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.
+  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.
 
@@ -4264,13 +4081,12 @@
     ]
     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.
+      # 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",
     ]
   }
 
-
 ```
 ## **bundle_executable_dir**: Expansion of {{bundle_executable_dir}} in create_bundle.
 
@@ -4278,12 +4094,11 @@
   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".
+  {{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.
 
-
 ```
 ## **bundle_plugins_dir**: Expansion of {{bundle_plugins_dir}} in create_bundle.
 
@@ -4291,12 +4106,11 @@
   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".
+  {{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.
 
-
 ```
 ## **bundle_resources_dir**: Expansion of {{bundle_resources_dir}} in create_bundle.
 
@@ -4304,12 +4118,11 @@
   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".
+  {{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.
 
-
 ```
 ## **bundle_root_dir**: Expansion of {{bundle_root_dir}} in create_bundle.
 
@@ -4317,8 +4130,8 @@
   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.
+  {{bundle_root_dir}} of the "bundle_data" target it depends on. This must
+  correspond to a path under root_build_dir.
 
 ```
 
@@ -4338,20 +4151,19 @@
     bundle_plugins_dir = bundle_root_dir + "/PlugIns"
   }
 
-
 ```
 ## **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.
+  "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".
+  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.
 
@@ -4381,13 +4193,13 @@
 ```
   A list of strings.
 
-  "cflags" are passed to all invocations of the C, C++, Objective C,
-  and Objective C++ compilers.
+  "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".
+  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.
 
@@ -4417,13 +4229,13 @@
 ```
   A list of strings.
 
-  "cflags" are passed to all invocations of the C, C++, Objective C,
-  and Objective C++ compilers.
+  "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".
+  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.
 
@@ -4453,13 +4265,13 @@
 ```
   A list of strings.
 
-  "cflags" are passed to all invocations of the C, C++, Objective C,
-  and Objective C++ compilers.
+  "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".
+  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.
 
@@ -4489,13 +4301,13 @@
 ```
   A list of strings.
 
-  "cflags" are passed to all invocations of the C, C++, Objective C,
-  and Objective C++ compilers.
+  "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".
+  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.
 
@@ -4523,20 +4335,20 @@
 ## **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 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.
+  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").
+  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.
+  The topic "gn help check" has general information on how checking works and
+  advice on how to pass a check in problematic cases.
 
 ```
 
@@ -4549,77 +4361,70 @@
     ...
   }
 
-
 ```
 ## **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.
+  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".
 
-
 ```
 ## **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.
+  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".
 
+```
+## **code_signing_script**: [file name] Script for code signing."
 
 ```
-## **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.
+  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".
 
-
 ```
 ## **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.
+  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".
 
-
 ```
 ## **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.
+  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.
+  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.
+  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.
+  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.
 
 ```
 
@@ -4631,7 +4436,6 @@
     deps = [ "bar" ]
   }
 
-
 ```
 ## **configs**: Configs applying to this target or config.
 
@@ -4643,45 +4447,44 @@
 ### **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.
+  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.
+  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.
+  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.
+  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:
+  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.
+   - 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.)
+   - 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.)
 
 ```
 
@@ -4716,11 +4519,10 @@
     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.
+  # 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 = [ ... ]
   }
@@ -4732,21 +4534,19 @@
     }
   }
 
-
 ```
 ## **console**: Run this action in the console pool.
 
 ```
   Boolean. Defaults to false.
 
-  Actions marked "console = true" will be run in the built-in ninja
-  "console" pool. They will have access to real stdin and stdout, and
-  output will not be buffered by ninja. This can be useful for
-  long-running actions with progress logs, or actions that require user 
-  input.
+  Actions marked "console = true" will be run in the built-in ninja "console"
+  pool. They will have access to real stdin and stdout, and output will not be
+  buffered by ninja. This can be useful for long-running actions with progress
+  logs, or actions that require user input.
 
-  Only one console pool target can run at any one time in Ninja. Refer
-  to the Ninja documentation on the console pool for more info.
+  Only one console pool target can run at any one time in Ninja. Refer to the
+  Ninja documentation on the console pool for more info.
 
 ```
 
@@ -4757,55 +4557,51 @@
     console = true
   }
 
-
 ```
 ## **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".
+  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".
+  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.
+  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.
+  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 OS X, create_bundle targets will not be recursed
-  into when gathering data. See "gn help create_bundle" for details.
+  Note: On iOS and OS X, 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.
 
-
 ```
 ## **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.
+  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.
+  This is normally used for things like plugins or helper programs that a
+  target needs at runtime.
 
-  Note: On iOS and OS X, create_bundle targets will not be recursed
-  into when gathering data_deps. See "gn help create_bundle" for
-  details.
+  Note: On iOS and OS X, 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".
 
@@ -4819,15 +4615,14 @@
     data_deps = [ "//plugins:my_runtime_plugin" ]
   }
 
-
 ```
 ## **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.
+  These strings will be passed to the C/C++ compiler as #defines. The strings
+  may or may not include an "=" to assign a value.
 
 ```
 
@@ -4855,22 +4650,29 @@
 ```
   defines = [ "AWESOME_FEATURE", "LOG_LEVEL=3" ]
 
-
 ```
 ## **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.
+  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.
 
-  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 of the paths should be
-  relative to the root build directory.
+  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.
 
 ```
 
@@ -4889,7 +4691,6 @@
     args = [ "{{source}}", "-o", depfile ]
   }
 
-
 ```
 ## **deps**: Private linked dependencies.
 
@@ -4897,43 +4698,42 @@
   A list of target labels.
 
   Specifies private dependencies of a target. Private dependencies are
-  propagated up the dependency tree and linked to dependant targets, but
-  do not grant the ability to include headers from the dependency.
-  Public configs are not forwarded.
+  propagated up the dependency tree and linked to dependant 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.
+  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 dependants to link to it.
+  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
+  dependants 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.
+  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".
+  Data dependencies are propagated differently. See "gn help data_deps" and
+  "gn help runtime_deps".
 
   See also "public_deps".
 
-
 ```
 ## **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.
+  The directories in this list will be added to the include path for the files
+  in the affected target.
 
 ```
 
@@ -4961,14 +4761,13 @@
 ```
   include_dirs = [ "src/include", "//third_party/foo" ]
 
-
 ```
 ## **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 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.
 
@@ -4977,42 +4776,40 @@
 ### **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 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.
+  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.
+  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.
+  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.
+  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.
 
 ```
 
@@ -5020,15 +4817,14 @@
 
 ```
   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.
+  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.
+  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.
 
 ```
 
@@ -5040,7 +4836,6 @@
     inputs = [ "input.data" ]
   }
 
-
 ```
 ## **ldflags**: Flags passed to the linker.
 
@@ -5048,13 +4843,13 @@
   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.
+  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.
+  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.
 
 ```
 
@@ -5082,9 +4877,9 @@
 ```
   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.
+  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
@@ -5122,15 +4917,14 @@
 ```
   lib_dirs = [ "/usr/lib/foo", "lib/doom_melon" ]
 
-
 ```
 ## **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.
+  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
@@ -5146,26 +4940,25 @@
   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.
+      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_prefix" 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_prefix" of the tool.
+      Values not containing '/' will be treated as system library names. These
+      will be passed unmodified to the linker and prefixed with the
+      "lib_prefix" 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_prefix"
+      of the tool.
 
   Apple frameworks
-      System libraries ending in ".framework" will be special-cased:
-      the switch "-framework" will be prepended instead of the
-      lib_prefix, and the ".framework" suffix will be trimmed. This is
-      to support the way Mac links framework dependencies.
+      System libraries ending in ".framework" will be special-cased: the switch
+      "-framework" will be prepended instead of the lib_prefix, and the
+      ".framework" suffix will be trimmed. This is to support the way Mac links
+      framework dependencies.
 
 ```
 
@@ -5201,25 +4994,24 @@
   On Linux:
     libs = [ "ld" ]
 
-
 ```
 ## **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.
+  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.
+  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.
+  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.
 
 ```
 
@@ -5231,23 +5023,21 @@
     ...
   }
 
-
 ```
 ## **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).
+  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.
+  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".
+  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".
 
 ```
 
@@ -5262,8 +5052,8 @@
     ...
   }
 
-  # On Windows, generate a "mysettings.cpl" control panel applet.
-  # Control panel applets are actually special shared libraries.
+  # 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"
@@ -5271,24 +5061,22 @@
     }
   }
 
-
 ```
 ## **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).
+  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.
+  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.
+  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.
 
@@ -5301,20 +5089,17 @@
     output_name = "fluffy_bunny"
   }
 
-
 ```
 ## **output_prefix_override**: Don't use prefix for output name.
 
 ```
-  A boolean that overrides the output prefix for a target. Defaults to
-  false.
+  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".
+  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.
+  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".
 
@@ -5324,74 +5109,69 @@
 
 ```
   shared_library("doom_melon") {
-    # Normally this will produce "libdoom_melon.so" on Linux, setting
-    # Setting this flag will produce "doom_melon.so".
+    # Normally this will produce "libdoom_melon.so" on Linux. Setting this flag
+    # will produce "doom_melon.so".
     output_prefix_override = true
     ...
   }
 
-
 ```
 ## **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.
+  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".
+    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_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".
-
+    Action targets (excluding action_foreach) must list literal output file(s)
+    with no source expansions. See "gn help action".
 
 ```
 ## **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.
+  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.
 
-  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.
+  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.
 
 ```
 
 ### **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).
+  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.
+  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.
 
-  If you use both C and C++ sources, the precompiled header and source
-  file will be compiled using both tools. You will want to make sure
-  to wrap C++ includes in __cplusplus #ifdefs so the file will compile
-  in C mode.
+  If you use both C and C++ sources, the precompiled header and source file
+  will be compiled using both tools. You will want to make sure to wrap C++
+  includes in __cplusplus #ifdefs so the file will compile in C mode.
 
   For example, if the toolchain specifies MSVC headers:
 
@@ -5419,15 +5199,13 @@
       ...
 
 
-
 ```
 ## **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".
-
+  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".
 
 ```
 ## **product_type**: Product type for Xcode projects.
@@ -5436,36 +5214,34 @@
   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.
-
+  When generating Xcode project files, only create_bundle target with a
+  non-empty product_type will have a corresponding target in Xcode project.
 
 ```
 ## **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").
+  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.
+  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.
 
-  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.
+  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.
+  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.
+  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.
 
 ```
 
@@ -5478,23 +5254,21 @@
   No files are public (no targets may include headers from this one):
     public = []
 
-
 ```
 ## **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.
+  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 then 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.
+  dependencies have been resolved. Therefore, a target will not see these
+  force-added configs in their "configs" variable while the script is running,
+  and then 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".
 
@@ -5522,40 +5296,37 @@
 ## **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.
+  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_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).
+    - 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.
+    - 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.
+  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.
+  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.
+  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.
 
 ```
 
@@ -5573,26 +5344,25 @@
     public_deps = [ ":c" ]
   }
 
-
 ```
 ## **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.
+  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.
+  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)".
+  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)".
 
 ```
 
@@ -5614,40 +5384,38 @@
     ]
   }
 
-
 ```
 ## **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").
-
+  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").
 
 ```
 ## **sources**: Source files for a target
 
 ```
-  A list of files. Non-absolute paths will be resolved relative to the
-  current build file.
+  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 existance of those
-  files for the purposes of include checking.
+  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 existance 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 preceeding "/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).
+  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
+  preceeding "/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).
 
 ```
 
@@ -5655,29 +5423,28 @@
 
 ```
   action_foreach
-    The sources are the set of files that the script will be executed
-    over. The script will run once per file.
+    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.
+    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.
 
-
 ```
 ## **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.
+  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.
+  This feature is intended to prevent accidentally shipping test code in a
+  final product.
 
 ```
 
@@ -5689,35 +5456,33 @@
     ...
   }
 
-
 ```
 ## **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").
+  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.
+  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.
+  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.
+  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.
 
 ```
 
@@ -5749,44 +5514,41 @@
   any targets in "//bar/" and any subdirectory thereof.
     visibility = [ "./*", "//bar/*" ]
 
-
 ```
 ## **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.
+  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.
+  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.
+  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").
-
+  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").
 
 ```
 ## **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.
+  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:
+  First, system default arguments are set based on the current system. The
+  built-in arguments are:
    - host_cpu
    - host_os
    - current_cpu
@@ -5794,20 +5556,18 @@
    - target_cpu
    - target_os
 
-  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).
+  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.
+  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.
+  If you specify an override for a build argument that never appears in a
+  "declare_args" call, a nonfatal error will be displayed.
 
 ```
 
@@ -5821,43 +5581,40 @@
           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.)
+      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.
+  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.
+  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.
 
 
 ```
 ## **.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
+  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.
+  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:
+  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
 
@@ -5867,29 +5624,27 @@
 
 ```
   buildconfig [required]
-      Label of the build config file. This file will be used to set up
-      the build file execution environment for each toolchain.
+      Label of 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.
+      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.
+      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.
+      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.
+      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.
 
@@ -5900,19 +5655,19 @@
         ]
 
   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.
+      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.
 
   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).
+      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.
+      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.
 
@@ -5932,16 +5687,15 @@
 
   secondary_source = "//build/config/temporary_buildfiles/"
 
-
 ```
 ## **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.
+  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.
 
 ```
 
@@ -5953,8 +5707,8 @@
 
   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.
+  White space and comments are ignored except that they may separate tokens
+  that would otherwise combine into a single token.
 
 ```
 
@@ -5972,8 +5726,7 @@
 ### **Keywords**
 
 ```
-  The following keywords are reserved and may not be used as
-  identifiers:
+  The following keywords are reserved and may not be used as identifiers:
 
           else    false   if      true
 
@@ -5998,10 +5751,12 @@
 
       string           = `"` { char | escape | expansion } `"` .
       escape           = `\` ( "$" | `"` | char ) .
-      BracketExpansion = "{" ( identifier | ArrayAccess | ScopeAccess ) "}" .
+      BracketExpansion = "{" ( identifier | ArrayAccess | ScopeAccess "
+                         ") "}" .
       Hex              = "0x" [0-9A-Fa-f][0-9A-Fa-f]
       expansion        = "$" ( identifier | BracketExpansion | Hex ) .
-      char             = /* any character except "$", `"`, or newline */ .
+      char             = /* any character except "$", `"`, or newline "
+                        "*/ .
 
   After a backslash, certain sequences represent special characters:
 
@@ -6011,15 +5766,15 @@
 
   All other backslashes represent themselves.
 
-  To insert an arbitrary byte value, use $0xFF. For example, to
-  insert a newline character: "Line one$0x0ALine two".
+  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:
+  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.
+  Use the "${var_one}" format to be explicitly deliniate the variable for
+  otherwise-ambiguous cases.
 
 ```
 
@@ -6078,21 +5833,21 @@
 ```
   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.
+   - 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.
+   - 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.
+   - 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.
+   - Scopes: Scopes are like dictionaries that use variable names for keys. See
+     "Scopes" below for more.
 
 ```
 
@@ -6103,56 +5858,54 @@
 
        mylist = [ 0, 1, 2, "some string" ]
 
-  A comma after the last item is optional. Lists are dereferenced using
-  0-based indexing:
+  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.
+  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.
+  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:
+  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.
+  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.
+  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.
+  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:
+  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 = {
@@ -6160,41 +5913,39 @@
       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:
+  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 ]
 
-
 ```
 ## **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.
+  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.
+      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.
+      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:
+      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":
+      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
 
@@ -6202,34 +5953,33 @@
       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:
+      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.
+      Note that if the input is empty, the result will be a null value which
+      will produce an error if assigned to a variable.
 
   "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.
+      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.
 
-
 ```
 ## **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.
+  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:
 
@@ -6246,41 +5996,38 @@
        "//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).
+  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.
+        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.
 
-
 ```
 ## **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.
+  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:
+  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:
+  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") {
       ...
@@ -6289,79 +6036,78 @@
         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.
+  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".
-
+  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".
 
 ```
 ## **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").
+  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.
+  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.
+  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.
+  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.
+  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:
+  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:
+  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 it's 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.
+   - List the outputs of the action in it's 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.
 
 ```
 
@@ -6369,43 +6115,41 @@
 
 ```
   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).
+  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.
-
+  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.
 
 ```
 ## **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.
+  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).
+  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.
+  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.
+  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.
+  See "gn help copy" and "gn help action_foreach" for more on how this is
+  applied.
 
 ```
 
@@ -6413,13 +6157,11 @@
 
 ```
   This section discusses only placeholders for actions. There are other
-  placeholders used in the definition of tools. See "gn help tool" for
-  those.
+  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.
+      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}}
@@ -6427,38 +6169,34 @@
         "//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.
+      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.
+      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.
+      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.
+      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.
+      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"
 
 ```
@@ -6466,18 +6204,17 @@
 ### **(*) 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.
+  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.
+  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.
 
 ```
 
@@ -6504,7 +6241,6 @@
     //out/Debug/obj/mydirectory/input2.h
     //out/Debug/obj/mydirectory/input2.cc
 
-
 ```
 **Available global switches
 **  Do "gn help --the_switch_you_want_help_on" for more. Individual
diff --git a/tools/gn/function_exec_script.cc b/tools/gn/function_exec_script.cc
index 231693b..8c4909c 100644
--- a/tools/gn/function_exec_script.cc
+++ b/tools/gn/function_exec_script.cc
@@ -63,57 +63,57 @@
 const char kExecScript_HelpShort[] =
     "exec_script: Synchronously run a script and return the output.";
 const char kExecScript_Help[] =
-    "exec_script: Synchronously run a script and return the output.\n"
-    "\n"
-    "  exec_script(filename,\n"
-    "              arguments = [],\n"
-    "              input_conversion = \"\",\n"
-    "              file_dependencies = [])\n"
-    "\n"
-    "  Runs the given script, returning the stdout of the script. The build\n"
-    "  generation will fail if the script does not exist or returns a nonzero\n"
-    "  exit code.\n"
-    "\n"
-    "  The current directory when executing the script will be the root\n"
-    "  build directory. If you are passing file names, you will want to use\n"
-    "  the rebase_path() function to make file names relative to this\n"
-    "  path (see \"gn help rebase_path\").\n"
-    "\n"
-    "Arguments:\n"
-    "\n"
-    "  filename:\n"
-    "      File name of python script to execute. Non-absolute names will\n"
-    "      be treated as relative to the current build file.\n"
-    "\n"
-    "  arguments:\n"
-    "      A list of strings to be passed to the script as arguments.\n"
-    "      May be unspecified or the empty list which means no arguments.\n"
-    "\n"
-    "  input_conversion:\n"
-    "      Controls how the file is read and parsed.\n"
-    "      See \"gn help input_conversion\".\n"
-    "\n"
-    "      If unspecified, defaults to the empty string which causes the\n"
-    "      script result to be discarded. exec script will return None.\n"
-    "\n"
-    "  dependencies:\n"
-    "      (Optional) A list of files that this script reads or otherwise\n"
-    "      depends on. These dependencies will be added to the build result\n"
-    "      such that if any of them change, the build will be regenerated and\n"
-    "      the script will be re-run.\n"
-    "\n"
-    "      The script itself will be an implicit dependency so you do not\n"
-    "      need to list it.\n"
-    "\n"
-    "Example:\n"
-    "\n"
-    "  all_lines = exec_script(\n"
-    "      \"myscript.py\", [some_input], \"list lines\",\n"
-    "      [ rebase_path(\"data_file.txt\", root_build_dir) ])\n"
-    "\n"
-    "  # This example just calls the script with no arguments and discards\n"
-    "  # the result.\n"
-    "  exec_script(\"//foo/bar/myscript.py\")\n";
+    R"(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")
+)";
 
 Value RunExecScript(Scope* scope,
                     const FunctionCallNode* function,
diff --git a/tools/gn/function_foreach.cc b/tools/gn/function_foreach.cc
index c264e3c..e94fbe6 100644
--- a/tools/gn/function_foreach.cc
+++ b/tools/gn/function_foreach.cc
@@ -14,35 +14,36 @@
 const char kForEach_HelpShort[] =
     "foreach: Iterate over a list.";
 const char kForEach_Help[] =
-    "foreach: Iterate over a list.\n"
-    "\n"
-    "  foreach(<loop_var>, <list>) {\n"
-    "    <loop contents>\n"
-    "  }\n"
-    "\n"
-    "  Executes the loop contents block over each item in the list,\n"
-    "  assigning the loop_var to each item in sequence. The loop_var will be\n"
-    "  a copy so assigning to it will not mutate the list.\n"
-    "\n"
-    "  The block does not introduce a new scope, so that variable assignments\n"
-    "  inside the loop will be visible once the loop terminates.\n"
-    "\n"
-    "  The loop variable will temporarily shadow any existing variables with\n"
-    "  the same name for the duration of the loop. After the loop terminates\n"
-    "  the loop variable will no longer be in scope, and the previous value\n"
-    "  (if any) will be restored.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  mylist = [ \"a\", \"b\", \"c\" ]\n"
-    "  foreach(i, mylist) {\n"
-    "    print(i)\n"
-    "  }\n"
-    "\n"
-    "  Prints:\n"
-    "  a\n"
-    "  b\n"
-    "  c\n";
+    R"(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 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
+)";
 
 Value RunForEach(Scope* scope,
                  const FunctionCallNode* function,
diff --git a/tools/gn/function_forward_variables_from.cc b/tools/gn/function_forward_variables_from.cc
index 0445f8b..7c92ec3 100644
--- a/tools/gn/function_forward_variables_from.cc
+++ b/tools/gn/function_forward_variables_from.cc
@@ -81,82 +81,80 @@
 const char kForwardVariablesFrom_HelpShort[] =
     "forward_variables_from: Copies variables from a different scope.";
 const char kForwardVariablesFrom_Help[] =
-    "forward_variables_from: Copies variables from a different scope.\n"
-    "\n"
-    "  forward_variables_from(from_scope, variable_list_or_star,\n"
-    "                         variable_to_not_forward_list = [])\n"
-    "\n"
-    "  Copies the given variables from the given scope to the local scope\n"
-    "  if they exist. This is normally used in the context of templates to\n"
-    "  use the values of variables defined in the template invocation to\n"
-    "  a template-defined target.\n"
-    "\n"
-    "  The variables in the given variable_list will be copied if they exist\n"
-    "  in the given scope or any enclosing scope. If they do not exist,\n"
-    "  nothing will happen and they be left undefined in the current scope.\n"
-    "\n"
-    "  As a special case, if the variable_list is a string with the value of\n"
-    "  \"*\", all variables from the given scope will be copied. \"*\" only\n"
-    "  copies variables set directly on the from_scope, not enclosing ones.\n"
-    "  Otherwise it would duplicate all global variables.\n"
-    "\n"
-    "  When an explicit list of variables is supplied, if the variable exists\n"
-    "  in the current (destination) scope already, an error will be thrown.\n"
-    "  If \"*\" is specified, variables in the current scope will be\n"
-    "  clobbered (the latter is important because most targets have an\n"
-    "  implicit configs list, which means it wouldn't work at all if it\n"
-    "  didn't clobber).\n"
-    "\n"
-    "  The sources assignment filter (see \"gn help "
-          "set_sources_assignment_filter\")\n"
-    "  is never applied by this function. It's assumed than any desired\n"
-    "  filtering was already done when sources was set on the from_scope.\n"
-    "\n"
-    "  If variables_to_not_forward_list is non-empty, then it must contains\n"
-    "  a list of variable names that will not be forwarded. This is mostly\n"
-    "  useful when variable_list_or_star has a value of \"*\".\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  # This is a common action template. It would invoke a script with\n"
-    "  # some given parameters, and wants to use the various types of deps\n"
-    "  # and the visibility from the invoker if it's defined. It also injects\n"
-    "  # an additional dependency to all targets.\n"
-    "  template(\"my_test\") {\n"
-    "    action(target_name) {\n"
-    "      forward_variables_from(invoker, [ \"data_deps\", \"deps\",\n"
-    "                                        \"public_deps\", \"visibility\" "
-                                                                         "])\n"
-    "      # Add our test code to the dependencies.\n"
-    "      # \"deps\" may or may not be defined at this point.\n"
-    "      if (defined(deps)) {\n"
-    "        deps += [ \"//tools/doom_melon\" ]\n"
-    "      } else {\n"
-    "        deps = [ \"//tools/doom_melon\" ]\n"
-    "      }\n"
-    "    }\n"
-    "  }\n"
-    "\n"
-    "  # This is a template around either a target whose type depends on a\n"
-    "  # global variable. It forwards all values from the invoker.\n"
-    "  template(\"my_wrapper\") {\n"
-    "    target(my_wrapper_target_type, target_name) {\n"
-    "      forward_variables_from(invoker, \"*\")\n"
-    "    }\n"
-    "  }\n"
-    "\n"
-    "  # A template that wraps another. It adds behavior based on one \n"
-    "  # variable, and forwards all others to the nested target.\n"
-    "  template(\"my_ios_test_app\") {\n"
-    "    ios_test_app(target_name) {\n"
-    "      forward_variables_from(invoker, \"*\", [\"test_bundle_name\"])\n"
-    "      if (!defined(extra_substitutions)) {\n"
-    "        extra_substitutions = []\n"
-    "      }\n"
-    "      extra_substitutions += [ \"BUNDLE_ID_TEST_NAME=$test_bundle_name\" "
-                                                                          "]\n"
-    "    }\n"
-    "  }\n";
+    R"(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" ]
+    }
+  }
+)";
 
 // This function takes a ListNode rather than a resolved vector of values
 // both avoid copying the potentially-large source scope, and so the variables
diff --git a/tools/gn/function_get_label_info.cc b/tools/gn/function_get_label_info.cc
index 58cb964..267c7b0 100644
--- a/tools/gn/function_get_label_info.cc
+++ b/tools/gn/function_get_label_info.cc
@@ -15,71 +15,65 @@
 const char kGetLabelInfo_HelpShort[] =
     "get_label_info: Get an attribute from a target's label.";
 const char kGetLabelInfo_Help[] =
-    "get_label_info: Get an attribute from a target's label.\n"
-    "\n"
-    "  get_label_info(target_label, what)\n"
-    "\n"
-    "  Given the label of a target, returns some attribute of that target.\n"
-    "  The target need not have been previously defined in the same file,\n"
-    "  since none of the attributes depend on the actual target definition,\n"
-    "  only the label itself.\n"
-    "\n"
-    "  See also \"gn help get_target_outputs\".\n"
-    "\n"
-    "Possible values for the \"what\" parameter\n"
-    "\n"
-    "  \"name\"\n"
-    "      The short name of the target. This will match the value of the\n"
-    "      \"target_name\" variable inside that target's declaration. For the\n"
-    "      label \"//foo/bar:baz\" this will return \"baz\".\n"
-    "\n"
-    "  \"dir\"\n"
-    "      The directory containing the target's definition, with no slash at\n"
-    "      the end. For the label \"//foo/bar:baz\" this will return\n"
-    "      \"//foo/bar\".\n"
-    "\n"
-    "  \"target_gen_dir\"\n"
-    "      The generated file directory for the target. This will match the\n"
-    "      value of the \"target_gen_dir\" variable when inside that target's\n"
-    "      declaration.\n"
-    "\n"
-    "  \"root_gen_dir\"\n"
-    "      The root of the generated file tree for the target. This will\n"
-    "      match the value of the \"root_gen_dir\" variable when inside that\n"
-    "      target's declaration.\n"
-    "\n"
-    "  \"target_out_dir\n"
-    "      The output directory for the target. This will match the\n"
-    "      value of the \"target_out_dir\" variable when inside that target's\n"
-    "      declaration.\n"
-    "\n"
-    "  \"root_out_dir\"\n"
-    "      The root of the output file tree for the target. This will\n"
-    "      match the value of the \"root_out_dir\" variable when inside that\n"
-    "      target's declaration.\n"
-    "\n"
-    "  \"label_no_toolchain\"\n"
-    "      The fully qualified version of this label, not including the\n"
-    "      toolchain. For the input \":bar\" it might return\n"
-    "      \"//foo:bar\".\n"
-    "\n"
-    "  \"label_with_toolchain\"\n"
-    "      The fully qualified version of this label, including the\n"
-    "      toolchain. For the input \":bar\" it might return\n"
-    "      \"//foo:bar(//toolchain:x64)\".\n"
-    "\n"
-    "  \"toolchain\"\n"
-    "      The label of the toolchain. This will match the value of the\n"
-    "      \"current_toolchain\" variable when inside that target's\n"
-    "      declaration.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  get_label_info(\":foo\", \"name\")\n"
-    "  # Returns string \"foo\".\n"
-    "\n"
-    "  get_label_info(\"//foo/bar:baz\", \"gen_dir\")\n"
-    "  # Returns string \"//out/Debug/gen/foo/bar\".\n";
+    R"*(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", "gen_dir")
+  # Returns string "//out/Debug/gen/foo/bar".
+)*";
 
 Value RunGetLabelInfo(Scope* scope,
                       const FunctionCallNode* function,
diff --git a/tools/gn/function_get_path_info.cc b/tools/gn/function_get_path_info.cc
index c14f416..1c542aa 100644
--- a/tools/gn/function_get_path_info.cc
+++ b/tools/gn/function_get_path_info.cc
@@ -121,82 +121,81 @@
 const char kGetPathInfo_HelpShort[] =
     "get_path_info: Extract parts of a file or directory name.";
 const char kGetPathInfo_Help[] =
-    "get_path_info: Extract parts of a file or directory name.\n"
-    "\n"
-    "  get_path_info(input, what)\n"
-    "\n"
-    "  The first argument is either a string representing a file or\n"
-    "  directory name, or a list of such strings. If the input is a list\n"
-    "  the return value will be a list containing the result of applying the\n"
-    "  rule to each item in the input.\n"
-    "\n"
-    "Possible values for the \"what\" parameter\n"
-    "\n"
-    "  \"file\"\n"
-    "      The substring after the last slash in the path, including the name\n"
-    "      and extension. If the input ends in a slash, the empty string will\n"
-    "      be returned.\n"
-    "        \"foo/bar.txt\" => \"bar.txt\"\n"
-    "        \"bar.txt\" => \"bar.txt\"\n"
-    "        \"foo/\" => \"\"\n"
-    "        \"\" => \"\"\n"
-    "\n"
-    "  \"name\"\n"
-    "     The substring of the file name not including the extension.\n"
-    "        \"foo/bar.txt\" => \"bar\"\n"
-    "        \"foo/bar\" => \"bar\"\n"
-    "        \"foo/\" => \"\"\n"
-    "\n"
-    "  \"extension\"\n"
-    "      The substring following the last period following the last slash,\n"
-    "      or the empty string if not found. The period is not included.\n"
-    "        \"foo/bar.txt\" => \"txt\"\n"
-    "        \"foo/bar\" => \"\"\n"
-    "\n"
-    "  \"dir\"\n"
-    "      The directory portion of the name, not including the slash.\n"
-    "        \"foo/bar.txt\" => \"foo\"\n"
-    "        \"//foo/bar\" => \"//foo\"\n"
-    "        \"foo\" => \".\"\n"
-    "\n"
-    "      The result will never end in a slash, so if the resulting\n"
-    "      is empty, the system (\"/\") or source (\"//\") roots, a \".\"\n"
-    "      will be appended such that it is always legal to append a slash\n"
-    "      and a filename and get a valid path.\n"
-    "\n"
-    "  \"out_dir\"\n"
-    "      The output file directory corresponding to the path of the\n"
-    "      given file, not including a trailing slash.\n"
-    "        \"//foo/bar/baz.txt\" => \"//out/Default/obj/foo/bar\"\n"
-    "\n"
-    "  \"gen_dir\"\n"
-    "      The generated file directory corresponding to the path of the\n"
-    "      given file, not including a trailing slash.\n"
-    "        \"//foo/bar/baz.txt\" => \"//out/Default/gen/foo/bar\"\n"
-    "\n"
-    "  \"abspath\"\n"
-    "      The full absolute path name to the file or directory. It will be\n"
-    "      resolved relative to the current directory, and then the source-\n"
-    "      absolute version will be returned. If the input is system-\n"
-    "      absolute, the same input will be returned.\n"
-    "        \"foo/bar.txt\" => \"//mydir/foo/bar.txt\"\n"
-    "        \"foo/\" => \"//mydir/foo/\"\n"
-    "        \"//foo/bar\" => \"//foo/bar\"  (already absolute)\n"
-    "        \"/usr/include\" => \"/usr/include\"  (already absolute)\n"
-    "\n"
-    "      If you want to make the path relative to another directory, or to\n"
-    "      be system-absolute, see rebase_path().\n"
-    "\n"
-    "Examples\n"
-    "  sources = [ \"foo.cc\", \"foo.h\" ]\n"
-    "  result = get_path_info(source, \"abspath\")\n"
-    "  # result will be [ \"//mydir/foo.cc\", \"//mydir/foo.h\" ]\n"
-    "\n"
-    "  result = get_path_info(\"//foo/bar/baz.cc\", \"dir\")\n"
-    "  # result will be \"//foo/bar\"\n"
-    "\n"
-    "  # Extract the source-absolute directory name,\n"
-    "  result = get_path_info(get_path_info(path, \"dir\"), \"abspath\")\n";
+    R"(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"
+)";
 
 Value RunGetPathInfo(Scope* scope,
                      const FunctionCallNode* function,
diff --git a/tools/gn/function_get_target_outputs.cc b/tools/gn/function_get_target_outputs.cc
index 4e1baf8..bec825f 100644
--- a/tools/gn/function_get_target_outputs.cc
+++ b/tools/gn/function_get_target_outputs.cc
@@ -16,57 +16,58 @@
 const char kGetTargetOutputs_HelpShort[] =
     "get_target_outputs: [file list] Get the list of outputs from a target.";
 const char kGetTargetOutputs_Help[] =
-    "get_target_outputs: [file list] Get the list of outputs from a target.\n"
-    "\n"
-    "  get_target_outputs(target_label)\n"
-    "\n"
-    "  Returns a list of output files for the named target. The named target\n"
-    "  must have been previously defined in the current file before this\n"
-    "  function is called (it can't reference targets in other files because\n"
-    "  there isn't a defined execution order, and it obviously can't\n"
-    "  reference targets that are defined after the function call).\n"
-    "\n"
-    "  Only copy and action targets are supported. The outputs from binary\n"
-    "  targets will depend on the toolchain definition which won't\n"
-    "  necessarily have been loaded by the time a given line of code has run,\n"
-    "  and source sets and groups have no useful output file.\n"
-    "\n"
-    "Return value\n"
-    "\n"
-    "  The names in the resulting list will be absolute file paths (normally\n"
-    "  like \"//out/Debug/bar.exe\", depending on the build directory).\n"
-    "\n"
-    "  action targets: this will just return the files specified in the\n"
-    "  \"outputs\" variable of the target.\n"
-    "\n"
-    "  action_foreach targets: this will return the result of applying\n"
-    "  the output template to the sources (see \"gn help source_expansion\").\n"
-    "  This will be the same result (though with guaranteed absolute file\n"
-    "  paths), as process_file_template will return for those inputs\n"
-    "  (see \"gn help process_file_template\").\n"
-    "\n"
-    "  binary targets (executables, libraries): this will return a list\n"
-    "  of the resulting binary file(s). The \"main output\" (the actual\n"
-    "  binary or library) will always be the 0th element in the result.\n"
-    "  Depending on the platform and output type, there may be other output\n"
-    "  files as well (like import libraries) which will follow.\n"
-    "\n"
-    "  source sets and groups: this will return a list containing the path of\n"
-    "  the \"stamp\" file that Ninja will produce once all outputs are\n"
-    "  generated. This probably isn't very useful.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  # Say this action generates a bunch of C source files.\n"
-    "  action_foreach(\"my_action\") {\n"
-    "    sources = [ ... ]\n"
-    "    outputs = [ ... ]\n"
-    "  }\n"
-    "\n"
-    "  # Compile the resulting source files into a source set.\n"
-    "  source_set(\"my_lib\") {\n"
-    "    sources = get_target_outputs(\":my_action\")\n"
-    "  }\n";
+    R"(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")
+  }
+)";
 
 Value RunGetTargetOutputs(Scope* scope,
                           const FunctionCallNode* function,
diff --git a/tools/gn/function_process_file_template.cc b/tools/gn/function_process_file_template.cc
index b7828a6..78889c9 100644
--- a/tools/gn/function_process_file_template.cc
+++ b/tools/gn/function_process_file_template.cc
@@ -17,45 +17,46 @@
 const char kProcessFileTemplate_HelpShort[] =
     "process_file_template: Do template expansion over a list of files.";
 const char kProcessFileTemplate_Help[] =
-    "process_file_template: Do template expansion over a list of files.\n"
-    "\n"
-    "  process_file_template(source_list, template)\n"
-    "\n"
-    "  process_file_template applies a template list to a source file list,\n"
-    "  returning the result of applying each template to each source. This is\n"
-    "  typically used for computing output file names from input files.\n"
-    "\n"
-    "  In most cases, get_target_outputs() will give the same result with\n"
-    "  shorter, more maintainable code. This function should only be used\n"
-    "  when that function can't be used (like there's no target or the target\n"
-    "  is defined in another build file).\n"
-    "\n"
-    "Arguments:\n"
-    "\n"
-    "  The source_list is a list of file names.\n"
-    "\n"
-    "  The template can be a string or a list. If it is a list, multiple\n"
-    "  output strings are generated for each input.\n"
-    "\n"
-    "  The template should contain source expansions to which each name in\n"
-    "  the source list is applied. See \"gn help source_expansion\".\n"
-    "\n"
-    "Example:\n"
-    "\n"
-    "  sources = [\n"
-    "    \"foo.idl\",\n"
-    "    \"bar.idl\",\n"
-    "  ]\n"
-    "  myoutputs = process_file_template(\n"
-    "      sources,\n"
-    "      [ \"$target_gen_dir/{{source_name_part}}.cc\",\n"
-    "        \"$target_gen_dir/{{source_name_part}}.h\" ])\n"
-    "\n"
-    " The result in this case will be:\n"
-    "    [ \"//out/Debug/foo.cc\"\n"
-    "      \"//out/Debug/foo.h\"\n"
-    "      \"//out/Debug/bar.cc\"\n"
-    "      \"//out/Debug/bar.h\" ]\n";
+    R"(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" ]
+)";
 
 Value RunProcessFileTemplate(Scope* scope,
                              const FunctionCallNode* function,
diff --git a/tools/gn/function_read_file.cc b/tools/gn/function_read_file.cc
index 11585d8..ed37ef0 100644
--- a/tools/gn/function_read_file.cc
+++ b/tools/gn/function_read_file.cc
@@ -20,24 +20,25 @@
 const char kReadFile_HelpShort[] =
     "read_file: Read a file into a variable.";
 const char kReadFile_Help[] =
-    "read_file: Read a file into a variable.\n"
-    "\n"
-    "  read_file(filename, input_conversion)\n"
-    "\n"
-    "  Whitespace will be trimmed from the end of the file. Throws an error\n"
-    "  if the file can not be opened.\n"
-    "\n"
-    "Arguments:\n"
-    "\n"
-    "  filename\n"
-    "      Filename to read, relative to the build file.\n"
-    "\n"
-    "  input_conversion\n"
-    "      Controls how the file is read and parsed.\n"
-    "      See \"gn help input_conversion\".\n"
-    "\n"
-    "Example\n"
-    "  lines = read_file(\"foo.txt\", \"list lines\")\n";
+    R"(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")
+)";
 
 Value RunReadFile(Scope* scope,
                   const FunctionCallNode* function,
diff --git a/tools/gn/function_rebase_path.cc b/tools/gn/function_rebase_path.cc
index f3b14bb..7626551 100644
--- a/tools/gn/function_rebase_path.cc
+++ b/tools/gn/function_rebase_path.cc
@@ -126,99 +126,95 @@
 const char kRebasePath_HelpShort[] =
     "rebase_path: Rebase a file or directory to another location.";
 const char kRebasePath_Help[] =
-    "rebase_path: Rebase a file or directory to another location.\n"
-    "\n"
-    "  converted = rebase_path(input,\n"
-    "                          new_base = \"\",\n"
-    "                          current_base = \".\")\n"
-    "\n"
-    "  Takes a string argument representing a file name, or a list of such\n"
-    "  strings and converts it/them to be relative to a different base\n"
-    "  directory.\n"
-    "\n"
-    "  When invoking the compiler or scripts, GN will automatically convert\n"
-    "  sources and include directories to be relative to the build directory.\n"
-    "  However, if you're passing files directly in the \"args\" array or\n"
-    "  doing other manual manipulations where GN doesn't know something is\n"
-    "  a file name, you will need to convert paths to be relative to what\n"
-    "  your tool is expecting.\n"
-    "\n"
-    "  The common case is to use this to convert paths relative to the\n"
-    "  current directory to be relative to the build directory (which will\n"
-    "  be the current directory when executing scripts).\n"
-    "\n"
-    "  If you want to convert a file path to be source-absolute (that is,\n"
-    "  beginning with a double slash like \"//foo/bar\"), you should use\n"
-    "  the get_path_info() function. This function won't work because it will\n"
-    "  always make relative paths, and it needs to support making paths\n"
-    "  relative to the source root, so can't also generate source-absolute\n"
-    "  paths without more special-cases.\n"
-    "\n"
-    "Arguments\n"
-    "\n"
-    "  input\n"
-    "      A string or list of strings representing file or directory names\n"
-    "      These can be relative paths (\"foo/bar.txt\"), system absolute\n"
-    "      paths (\"/foo/bar.txt\"), or source absolute paths\n"
-    "      (\"//foo/bar.txt\").\n"
-    "\n"
-    "  new_base\n"
-    "      The directory to convert the paths to be relative to. This can be\n"
-    "      an absolute path or a relative path (which will be treated\n"
-    "      as being relative to the current BUILD-file's directory).\n"
-    "\n"
-    "      As a special case, if new_base is the empty string (the default),\n"
-    "      all paths will be converted to system-absolute native style paths\n"
-    "      with system path separators. This is useful for invoking external\n"
-    "      programs.\n"
-    "\n"
-    "  current_base\n"
-    "      Directory representing the base for relative paths in the input.\n"
-    "      If this is not an absolute path, it will be treated as being\n"
-    "      relative to the current build file. Use \".\" (the default) to\n"
-    "      convert paths from the current BUILD-file's directory.\n"
-    "\n"
-    "Return value\n"
-    "\n"
-    "  The return value will be the same type as the input value (either a\n"
-    "  string or a list of strings). All relative and source-absolute file\n"
-    "  names will be converted to be relative to the requested output\n"
-    "  System-absolute paths will be unchanged.\n"
-    "\n"
-    "  Whether an output path will end in a slash will match whether the\n"
-    "  corresponding input path ends in a slash. It will return \".\" or\n"
-    "  \"./\" (depending on whether the input ends in a slash) to avoid\n"
-    "  returning empty strings. This means if you want a root path\n"
-    "  (\"//\" or \"/\") not ending in a slash, you can add a dot (\"//.\").\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  # Convert a file in the current directory to be relative to the build\n"
-    "  # directory (the current dir when executing compilers and scripts).\n"
-    "  foo = rebase_path(\"myfile.txt\", root_build_dir)\n"
-    "  # might produce \"../../project/myfile.txt\".\n"
-    "\n"
-    "  # Convert a file to be system absolute:\n"
-    "  foo = rebase_path(\"myfile.txt\")\n"
-    "  # Might produce \"D:\\source\\project\\myfile.txt\" on Windows or\n"
-    "  # \"/home/you/source/project/myfile.txt\" on Linux.\n"
-    "\n"
-    "  # Typical usage for converting to the build directory for a script.\n"
-    "  action(\"myscript\") {\n"
-    "    # Don't convert sources, GN will automatically convert these to be\n"
-    "    # relative to the build directory when it constructs the command\n"
-    "    # line for your script.\n"
-    "    sources = [ \"foo.txt\", \"bar.txt\" ]\n"
-    "\n"
-    "    # Extra file args passed manually need to be explicitly converted\n"
-    "    # to be relative to the build directory:\n"
-    "    args = [\n"
-    "      \"--data\",\n"
-    "      rebase_path(\"//mything/data/input.dat\", root_build_dir),\n"
-    "      \"--rel\",\n"
-    "      rebase_path(\"relative_path.txt\", root_build_dir)\n"
-    "    ] + rebase_path(sources, root_build_dir)\n"
-    "  }\n";
+    R"(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)
+  }
+)";
 
 Value RunRebasePath(Scope* scope,
                     const FunctionCallNode* function,
diff --git a/tools/gn/function_set_default_toolchain.cc b/tools/gn/function_set_default_toolchain.cc
index cc5929e..b9d3109 100644
--- a/tools/gn/function_set_default_toolchain.cc
+++ b/tools/gn/function_set_default_toolchain.cc
@@ -15,33 +15,33 @@
 const char kSetDefaultToolchain_HelpShort[] =
     "set_default_toolchain: Sets the default toolchain name.";
 const char kSetDefaultToolchain_Help[] =
-    "set_default_toolchain: Sets the default toolchain name.\n"
-    "\n"
-    "  set_default_toolchain(toolchain_label)\n"
-    "\n"
-    "  The given label should identify a toolchain definition (see\n"
-    "  \"help toolchain\"). This toolchain will be used for all targets\n"
-    "  unless otherwise specified.\n"
-    "\n"
-    "  This function is only valid to call during the processing of the build\n"
-    "  configuration file. Since the build configuration file is processed\n"
-    "  separately for each toolchain, this function will be a no-op when\n"
-    "  called under any non-default toolchains.\n"
-    "\n"
-    "  For example, the default toolchain should be appropriate for the\n"
-    "  current environment. If the current environment is 32-bit and \n"
-    "  somebody references a target with a 64-bit toolchain, we wouldn't\n"
-    "  want processing of the build config file for the 64-bit toolchain to\n"
-    "  reset the default toolchain to 64-bit, we want to keep it 32-bits.\n"
-    "\n"
-    "Argument:\n"
-    "\n"
-    "  toolchain_label\n"
-    "      Toolchain name.\n"
-    "\n"
-    "Example:\n"
-    "\n"
-    "  set_default_toolchain(\"//build/config/win:vs32\")";
+    R"(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("//build/config/win:vs32"))";
 
 Value RunSetDefaultToolchain(Scope* scope,
                              const FunctionCallNode* function,
diff --git a/tools/gn/function_set_defaults.cc b/tools/gn/function_set_defaults.cc
index 7f26b44..a2a14af 100644
--- a/tools/gn/function_set_defaults.cc
+++ b/tools/gn/function_set_defaults.cc
@@ -13,37 +13,37 @@
 const char kSetDefaults_HelpShort[] =
     "set_defaults: Set default values for a target type.";
 const char kSetDefaults_Help[] =
-    "set_defaults: Set default values for a target type.\n"
-    "\n"
-    "  set_defaults(<target_type_name>) { <values...> }\n"
-    "\n"
-    "  Sets the default values for a given target type. Whenever\n"
-    "  target_type_name is seen in the future, the values specified in\n"
-    "  set_default's block will be copied into the current scope.\n"
-    "\n"
-    "  When the target type is used, the variable copying is very strict.\n"
-    "  If a variable with that name is already in scope, the build will fail\n"
-    "  with an error.\n"
-    "\n"
-    "  set_defaults can be used for built-in target types (\"executable\",\n"
-    "  \"shared_library\", etc.) and custom ones defined via the \"template\"\n"
-    "  command. It can be called more than once and the most recent call in\n"
-    "  any scope will apply, but there is no way to refer to the previous\n"
-    "  defaults and modify them (each call to set_defaults must supply a\n"
-    "  complete list of all defaults it wants). If you want to share\n"
-    "  defaults, store them in a separate variable.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  set_defaults(\"static_library\") {\n"
-    "    configs = [ \"//tools/mything:settings\" ]\n"
-    "  }\n"
-    "\n"
-    "  static_library(\"mylib\")\n"
-    "    # The configs will be auto-populated as above. You can remove it if\n"
-    "    # you don't want the default for a particular default:\n"
-    "    configs -= \"//tools/mything:settings\"\n"
-    "  }\n";
+    R"(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" ]
+  }
+)";
 
 Value RunSetDefaults(Scope* scope,
                      const FunctionCallNode* function,
diff --git a/tools/gn/function_template.cc b/tools/gn/function_template.cc
index 6136f41..66c6801 100644
--- a/tools/gn/function_template.cc
+++ b/tools/gn/function_template.cc
@@ -15,148 +15,144 @@
 const char kTemplate_HelpShort[] =
     "template: Define a template rule.";
 const char kTemplate_Help[] =
-    "template: Define a template rule.\n"
-    "\n"
-    "  A template defines a custom name that acts like a function. It\n"
-    "  provides a way to add to the built-in target types.\n"
-    "\n"
-    "  The template() function is used to declare a template. To invoke the\n"
-    "  template, just use the name of the template like any other target\n"
-    "  type.\n"
-    "\n"
-    "  Often you will want to declare your template in a special file that\n"
-    "  other files will import (see \"gn help import\") so your template\n"
-    "  rule can be shared across build files.\n"
-    "\n"
-    "Variables and templates:\n"
-    "\n"
-    "  When you call template() it creates a closure around all variables\n"
-    "  currently in scope with the code in the template block. When the\n"
-    "  template is invoked, the closure will be executed.\n"
-    "\n"
-    "  When the template is invoked, the code in the caller is executed and\n"
-    "  passed to the template code as an implicit \"invoker\" variable. The\n"
-    "  template uses this to read state out of the invoking code.\n"
-    "\n"
-    "  One thing explicitly excluded from the closure is the \"current\n"
-    "  directory\" against which relative file names are resolved. The\n"
-    "  current directory will be that of the invoking code, since typically\n"
-    "  that code specifies the file names. This means all files internal\n"
-    "  to the template should use absolute names.\n"
-    "\n"
-    "  A template will typically forward some or all variables from the\n"
-    "  invoking scope to a target that it defines. Often, such variables\n"
-    "  might be optional. Use the pattern:\n"
-    "\n"
-    "    if (defined(invoker.deps)) {\n"
-    "      deps = invoker.deps\n"
-    "    }\n"
-    "\n"
-    "  The function forward_variables_from() provides a shortcut to forward\n"
-    "  one or more or possibly all variables in this manner:\n"
-    "\n"
-    "    forward_variables_from(invoker, [\"deps\", \"public_deps\"])\n"
-    "\n"
-    "Target naming:\n"
-    "\n"
-    "  Your template should almost always define a built-in target with the\n"
-    "  name the template invoker specified. For example, if you have an IDL\n"
-    "  template and somebody does:\n"
-    "    idl(\"foo\") {...\n"
-    "  you will normally want this to expand to something defining a\n"
-    "  source_set or static_library named \"foo\" (among other things you may\n"
-    "  need). This way, when another target specifies a dependency on\n"
-    "  \"foo\", the static_library or source_set will be linked.\n"
-    "\n"
-    "  It is also important that any other targets your template expands to\n"
-    "  have globally unique names, or you will get collisions.\n"
-    "\n"
-    "  Access the invoking name in your template via the implicit\n"
-    "  \"target_name\" variable. This should also be the basis for how other\n"
-    "  targets that a template expands to ensure uniqueness.\n"
-    "\n"
-    "  A typical example would be a template that defines an action to\n"
-    "  generate some source files, and a source_set to compile that source.\n"
-    "  Your template would name the source_set \"target_name\" because\n"
-    "  that's what you want external targets to depend on to link your code.\n"
-    "  And you would name the action something like \"${target_name}_action\"\n"
-    "  to make it unique. The source set would have a dependency on the\n"
-    "  action to make it run.\n"
-    "\n"
-    "Example of defining a template:\n"
-    "\n"
-    "  template(\"my_idl\") {\n"
-    "    # Be nice and help callers debug problems by checking that the\n"
-    "    # variables the template requires are defined. This gives a nice\n"
-    "    # message rather than giving the user an error about an\n"
-    "    # undefined variable in the file defining the template\n"
-    "    #\n"
-    "    # You can also use defined() to give default values to variables\n"
-    "    # unspecified by the invoker.\n"
-    "    assert(defined(invoker.sources),\n"
-    "           \"Need sources in $target_name listing the idl files.\")\n"
-    "\n"
-    "    # Name of the intermediate target that does the code gen. This must\n"
-    "    # incorporate the target name so it's unique across template\n"
-    "    # instantiations.\n"
-    "    code_gen_target_name = target_name + \"_code_gen\"\n"
-    "\n"
-    "    # Intermediate target to convert IDL to C source. Note that the name\n"
-    "    # is based on the name the invoker of the template specified. This\n"
-    "    # way, each time the template is invoked we get a unique\n"
-    "    # intermediate action name (since all target names are in the global\n"
-    "    # scope).\n"
-    "    action_foreach(code_gen_target_name) {\n"
-    "      # Access the scope defined by the invoker via the implicit\n"
-    "      # \"invoker\" variable.\n"
-    "      sources = invoker.sources\n"
-    "\n"
-    "      # Note that we need an absolute path for our script file name.\n"
-    "      # The current directory when executing this code will be that of\n"
-    "      # the invoker (this is why we can use the \"sources\" directly\n"
-    "      # above without having to rebase all of the paths). But if we need\n"
-    "      # to reference a script relative to the template file, we'll need\n"
-    "      # to use an absolute path instead.\n"
-    "      script = \"//tools/idl/idl_code_generator.py\"\n"
-    "\n"
-    "      # Tell GN how to expand output names given the sources.\n"
-    "      # See \"gn help source_expansion\" for more.\n"
-    "      outputs = [ \"$target_gen_dir/{{source_name_part}}.cc\",\n"
-    "                  \"$target_gen_dir/{{source_name_part}}.h\" ]\n"
-    "    }\n"
-    "\n"
-    "    # Name the source set the same as the template invocation so\n"
-    "    # instancing this template produces something that other targets\n"
-    "    # can link to in their deps.\n"
-    "    source_set(target_name) {\n"
-    "      # Generates the list of sources, we get these from the\n"
-    "      # action_foreach above.\n"
-    "      sources = get_target_outputs(\":$code_gen_target_name\")\n"
-    "\n"
-    "      # This target depends on the files produced by the above code gen\n"
-    "      # target.\n"
-    "      deps = [ \":$code_gen_target_name\" ]\n"
-    "    }\n"
-    "  }\n"
-    "\n"
-    "Example of invoking the resulting template:\n"
-    "\n"
-    "  # This calls the template code above, defining target_name to be\n"
-    "  # \"foo_idl_files\" and \"invoker\" to be the set of stuff defined in\n"
-    "  # the curly brackets.\n"
-    "  my_idl(\"foo_idl_files\") {\n"
-    "    # Goes into the template as \"invoker.sources\".\n"
-    "    sources = [ \"foo.idl\", \"bar.idl\" ]\n"
-    "  }\n"
-    "\n"
-    "  # Here is a target that depends on our template.\n"
-    "  executable(\"my_exe\") {\n"
-    "    # Depend on the name we gave the template call above. Internally,\n"
-    "    # this will produce a dependency from executable to the source_set\n"
-    "    # inside the template (since it has this name), which will in turn\n"
-    "    # depend on the code gen action.\n"
-    "    deps = [ \":foo_idl_files\" ]\n"
-    "  }\n";
+    R"(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.
+
+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" ]
+  }
+)";
 
 Value RunTemplate(Scope* scope,
                   const FunctionCallNode* function,
diff --git a/tools/gn/function_toolchain.cc b/tools/gn/function_toolchain.cc
index 9b08809..f42be6c 100644
--- a/tools/gn/function_toolchain.cc
+++ b/tools/gn/function_toolchain.cc
@@ -302,87 +302,83 @@
 const char kToolchain_HelpShort[] =
     "toolchain: Defines a toolchain.";
 const char kToolchain_Help[] =
-    "toolchain: Defines a toolchain.\n"
-    "\n"
-    "  A toolchain is a set of commands and build flags used to compile the\n"
-    "  source code. You can have more than one toolchain in use at once in\n"
-    "  a build.\n"
-    "\n"
-    "Functions and variables\n"
-    "\n"
-    "  tool()\n"
-    "    The tool() function call specifies the commands commands to run for\n"
-    "    a given step. See \"gn help tool\".\n"
-    "\n"
-    "  toolchain_args\n"
-    "    Overrides for build arguments to pass to the toolchain when invoking\n"
-    "    it. This is a variable of type \"scope\" where the variable names\n"
-    "    correspond to variables in declare_args() blocks.\n"
-    "\n"
-    "    When you specify a target using an alternate toolchain, the master\n"
-    "    build configuration file is re-interpreted in the context of that\n"
-    "    toolchain. toolchain_args allows you to control the arguments\n"
-    "    passed into this alternate invocation of the build.\n"
-    "\n"
-    "    Any default system arguments or arguments passed in via \"gn args\"\n"
-    "    will also be passed to the alternate invocation unless explicitly\n"
-    "    overridden by toolchain_args.\n"
-    "\n"
-    "    The toolchain_args will be ignored when the toolchain being defined\n"
-    "    is the default. In this case, it's expected you want the default\n"
-    "    argument values.\n"
-    "\n"
-    "    See also \"gn help buildargs\" for an overview of these arguments.\n"
-    "\n"
-    "  deps\n"
-    "    Dependencies of this toolchain. These dependencies will be resolved\n"
-    "    before any target in the toolchain is compiled. To avoid circular\n"
-    "    dependencies these must be targets defined in another toolchain.\n"
-    "\n"
-    "    This is expressed as a list of targets, and generally these targets\n"
-    "    will always specify a toolchain:\n"
-    "      deps = [ \"//foo/bar:baz(//build/toolchain:bootstrap)\" ]\n"
-    "\n"
-    "    This concept is somewhat inefficient to express in Ninja (it\n"
-    "    requires a lot of duplicate of rules) so should only be used when\n"
-    "    absolutely necessary.\n"
-    "\n"
-    "Invoking targets in toolchains:\n"
-    "\n"
-    "  By default, when a target depends on another, there is an implicit\n"
-    "  toolchain label that is inherited, so the dependee has the same one\n"
-    "  as the dependent.\n"
-    "\n"
-    "  You can override this and refer to any other toolchain by explicitly\n"
-    "  labeling the toolchain to use. For example:\n"
-    "    data_deps = [ \"//plugins:mine(//toolchains:plugin_toolchain)\" ]\n"
-    "  The string \"//build/toolchains:plugin_toolchain\" is a label that\n"
-    "  identifies the toolchain declaration for compiling the sources.\n"
-    "\n"
-    "  To load a file in an alternate toolchain, GN does the following:\n"
-    "\n"
-    "   1. Loads the file with the toolchain definition in it (as determined\n"
-    "      by the toolchain label).\n"
-    "   2. Re-runs the master build configuration file, applying the\n"
-    "      arguments specified by the toolchain_args section of the toolchain\n"
-    "      definition.\n"
-    "   3. Loads the destination build file in the context of the\n"
-    "      configuration file in the previous step.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  toolchain(\"plugin_toolchain\") {\n"
-    "    tool(\"cc\") {\n"
-    "      command = \"gcc {{source}}\"\n"
-    "      ...\n"
-    "    }\n"
-    "\n"
-    "    toolchain_args = {\n"
-    "      is_plugin = true\n"
-    "      is_32bit = true\n"
-    "      is_64bit = false\n"
-    "    }\n"
-    "  }\n";
+    R"*(toolchain: Defines a toolchain.
+
+  A toolchain is a set of commands and build flags used to compile the source
+  code. You can have more than one toolchain in use at once in a 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.
+
+Invoking targets in toolchains
+
+  By default, when a target depends on another, there is an implicit toolchain
+  label that is inherited, so the dependee has the same one as the dependent.
+
+  You can override this and refer to any other toolchain by explicitly
+  labeling the toolchain to use. For example:
+    data_deps = [ "//plugins:mine(//toolchains:plugin_toolchain)" ]
+  The string "//build/toolchains:plugin_toolchain" is a label that identifies
+  the toolchain declaration for compiling the sources.
+
+  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.
+
+Example
+
+  toolchain("plugin_toolchain") {
+    tool("cc") {
+      command = "gcc {{source}}"
+      ...
+    }
+
+    toolchain_args = {
+      is_plugin = true
+      is_32bit = true
+      is_64bit = false
+    }
+  };
+)*";
 
 Value RunToolchain(Scope* scope,
                    const FunctionCallNode* function,
@@ -459,468 +455,457 @@
 const char kTool_HelpShort[] =
     "tool: Specify arguments to a toolchain tool.";
 const char kTool_Help[] =
-    "tool: Specify arguments to a toolchain tool.\n"
-    "\n"
-    "Usage:\n"
-    "\n"
-    "  tool(<tool type>) {\n"
-    "    <tool variables...>\n"
-    "  }\n"
-    "\n"
-    "Tool types\n"
-    "\n"
-    "    Compiler tools:\n"
-    "      \"cc\": C compiler\n"
-    "      \"cxx\": C++ compiler\n"
-    "      \"objc\": Objective C compiler\n"
-    "      \"objcxx\": Objective C++ compiler\n"
-    "      \"rc\": Resource compiler (Windows .rc files)\n"
-    "      \"asm\": Assembler\n"
-    "\n"
-    "    Linker tools:\n"
-    "      \"alink\": Linker for static libraries (archives)\n"
-    "      \"solink\": Linker for shared libraries\n"
-    "      \"link\": Linker for executables\n"
-    "\n"
-    "    Other tools:\n"
-    "      \"stamp\": Tool for creating stamp files\n"
-    "      \"copy\": Tool to copy files.\n"
-    "\n"
-    "    Platform specific tools:\n"
-    "      \"copy_bundle_data\": [iOS, OS X] Tool to copy files in a bundle.\n"
-    "      \"compile_xcassets\": [iOS, OS X] Tool to compile asset catalogs.\n"
-    "\n"
-    "Tool variables\n"
-    "\n"
-    "    command  [string with substitutions]\n"
-    "        Valid for: all tools (required)\n"
-    "\n"
-    "        The command to run.\n"
-    "\n"
-    "    default_output_dir  [string with substitutions]\n"
-    "        Valid for: linker tools\n"
-    "\n"
-    "        Default directory name for the output file relative to the\n"
-    "        root_build_dir. It can contain other substitution patterns.\n"
-    "        This will be the default value for the {{output_dir}} expansion\n"
-    "        (discussed below) but will be overridden by the \"output_dir\"\n"
-    "        variable in a target, if one is specified.\n"
-    "\n"
-    "        GN doesn't do anything with this string other than pass it\n"
-    "        along, potentially with target-specific overrides. It is the\n"
-    "        tool's job to use the expansion so that the files will be in\n"
-    "        the right place.\n"
-    "\n"
-    "    default_output_extension  [string]\n"
-    "        Valid for: linker tools\n"
-    "\n"
-    "        Extension for the main output of a linkable tool. It includes\n"
-    "        the leading dot. This will be the default value for the\n"
-    "        {{output_extension}} expansion (discussed below) but will be\n"
-    "        overridden by by the \"output extension\" variable in a target,\n"
-    "        if one is specified. Empty string means no extension.\n"
-    "\n"
-    "        GN doesn't actually do anything with this extension other than\n"
-    "        pass it along, potentially with target-specific overrides. One\n"
-    "        would typically use the {{output_extension}} value in the\n"
-    "        \"outputs\" to read this value.\n"
-    "\n"
-    "        Example: default_output_extension = \".exe\"\n"
-    "\n"
-    "    depfile  [string with substitutions]\n"
-    "        Valid for: compiler tools (optional)\n"
-    "\n"
-    "        If the tool can write \".d\" files, this specifies the name of\n"
-    "        the resulting file. These files are used to list header file\n"
-    "        dependencies (or other implicit input dependencies) that are\n"
-    "        discovered at build time. See also \"depsformat\".\n"
-    "\n"
-    "        Example: depfile = \"{{output}}.d\"\n"
-    "\n"
-    "    depsformat  [string]\n"
-    "        Valid for: compiler tools (when depfile is specified)\n"
-    "\n"
-    "        Format for the deps outputs. This is either \"gcc\" or \"msvc\".\n"
-    "        See the ninja documentation for \"deps\" for more information.\n"
-    "\n"
-    "        Example: depsformat = \"gcc\"\n"
-    "\n"
-    "    description  [string with substitutions, optional]\n"
-    "        Valid for: all tools\n"
-    "\n"
-    "        What to print when the command is run.\n"
-    "\n"
-    "        Example: description = \"Compiling {{source}}\"\n"
-    "\n"
-    "    lib_switch  [string, optional, link tools only]\n"
-    "    lib_dir_switch  [string, optional, link tools only]\n"
-    "        Valid for: Linker tools except \"alink\"\n"
-    "\n"
-    "        These strings will be prepended to the libraries and library\n"
-    "        search directories, respectively, because linkers differ on how\n"
-    "        specify them. If you specified:\n"
-    "          lib_switch = \"-l\"\n"
-    "          lib_dir_switch = \"-L\"\n"
-    "        then the \"{{libs}}\" expansion for [ \"freetype\", \"expat\"]\n"
-    "        would be \"-lfreetype -lexpat\".\n"
-    "\n"
-    "    outputs  [list of strings with substitutions]\n"
-    "        Valid for: Linker and compiler tools (required)\n"
-    "\n"
-    "        An array of names for the output files the tool produces. These\n"
-    "        are relative to the build output directory. There must always be\n"
-    "        at least one output file. There can be more than one output (a\n"
-    "        linker might produce a library and an import library, for\n"
-    "        example).\n"
-    "\n"
-    "        This array just declares to GN what files the tool will\n"
-    "        produce. It is your responsibility to specify the tool command\n"
-    "        that actually produces these files.\n"
-    "\n"
-    "        If you specify more than one output for shared library links,\n"
-    "        you should consider setting link_output, depend_output, and\n"
-    "        runtime_outputs.\n"
-    "\n"
-    "        Example for a compiler tool that produces .obj files:\n"
-    "          outputs = [\n"
-    "            \"{{source_out_dir}}/{{source_name_part}}.obj\"\n"
-    "          ]\n"
-    "\n"
-    "        Example for a linker tool that produces a .dll and a .lib. The\n"
-    "        use of {{target_output_name}}, {{output_extension}} and\n"
-    "        {{output_dir}} allows the target to override these values.\n"
-    "          outputs = [\n"
-    "            \"{{output_dir}}/{{target_output_name}}"
-                     "{{output_extension}}\",\n"
-    "            \"{{output_dir}}/{{target_output_name}}.lib\",\n"
-    "          ]\n"
-    "\n"
-    "    pool [label, optional]\n"
-    "\n"
-    "        Label of the pool to use for the tool. Pools are used to limit\n"
-    "        the number of tasks that can execute concurrently during the\n"
-    "        build.\n"
-    "\n"
-    "        See also \"gn help pool\".\n"
-    "\n"
-    "    link_output  [string with substitutions]\n"
-    "    depend_output  [string with substitutions]\n"
-    "        Valid for: \"solink\" only (optional)\n"
-    "\n"
-    "        These two files specify which of the outputs from the solink\n"
-    "        tool should be used for linking and dependency tracking. These\n"
-    "        should match entries in the \"outputs\". If unspecified, the\n"
-    "        first item in the \"outputs\" array will be used for all. See\n"
-    "        \"Separate linking and dependencies for shared libraries\"\n"
-    "        below for more.\n"
-    "\n"
-    "        On Windows, where the tools produce a .dll shared library and\n"
-    "        a .lib import library, you will want the first two to be the\n"
-    "        import library and the third one to be the .dll file.\n"
-    "        On Linux, if you're not doing the separate linking/dependency\n"
-    "        optimization, all of these should be the .so output.\n"
-    "\n"
-    "    output_prefix  [string]\n"
-    "        Valid for: Linker tools (optional)\n"
-    "\n"
-    "        Prefix to use for the output name. Defaults to empty. This\n"
-    "        prefix will be prepended to the name of the target (or the\n"
-    "        output_name if one is manually specified for it) if the prefix\n"
-    "        is not already there. The result will show up in the\n"
-    "        {{output_name}} substitution pattern.\n"
-    "\n"
-    "        Individual targets can opt-out of the output prefix by setting:\n"
-    "          output_prefix_override = true\n"
-    "        (see \"gn help output_prefix_override\").\n"
-    "\n"
-    "        This is typically used to prepend \"lib\" to libraries on\n"
-    "        Posix systems:\n"
-    "          output_prefix = \"lib\"\n"
-    "\n"
-    "    precompiled_header_type  [string]\n"
-    "        Valid for: \"cc\", \"cxx\", \"objc\", \"objcxx\"\n"
-    "\n"
-    "        Type of precompiled headers. If undefined or the empty string,\n"
-    "        precompiled headers will not be used for this tool. Otherwise\n"
-    "        use \"gcc\" or \"msvc\".\n"
-    "\n"
-    "        For precompiled headers to be used for a given target, the\n"
-    "        target (or a config applied to it) must also specify a\n"
-    "        \"precompiled_header\" and, for \"msvc\"-style headers, a\n"
-    "        \"precompiled_source\" value. If the type is \"gcc\", then both\n"
-    "        \"precompiled_header\" and \"precompiled_source\" must resolve\n"
-    "        to the same file, despite the different formats required for each."
-    "\n"
-    "        See \"gn help precompiled_header\" for more.\n"
-    "\n"
-    "    restat  [boolean]\n"
-    "        Valid for: all tools (optional, defaults to false)\n"
-    "\n"
-    "        Requests that Ninja check the file timestamp after this tool has\n"
-    "        run to determine if anything changed. Set this if your tool has\n"
-    "        the ability to skip writing output if the output file has not\n"
-    "        changed.\n"
-    "\n"
-    "        Normally, Ninja will assume that when a tool runs the output\n"
-    "        be new and downstream dependents must be rebuild. When this is\n"
-    "        set to trye, Ninja can skip rebuilding downstream dependents for\n"
-    "        input changes that don't actually affect the output.\n"
-    "\n"
-    "        Example:\n"
-    "          restat = true\n"
-    "\n"
-    "    rspfile  [string with substitutions]\n"
-    "        Valid for: all tools (optional)\n"
-    "\n"
-    "        Name of the response file. If empty, no response file will be\n"
-    "        used. See \"rspfile_content\".\n"
-    "\n"
-    "    rspfile_content  [string with substitutions]\n"
-    "        Valid for: all tools (required when \"rspfile\" is specified)\n"
-    "\n"
-    "        The contents to be written to the response file. This may\n"
-    "        include all or part of the command to send to the tool which\n"
-    "        allows you to get around OS command-line length limits.\n"
-    "\n"
-    "        This example adds the inputs and libraries to a response file,\n"
-    "        but passes the linker flags directly on the command line:\n"
-    "          tool(\"link\") {\n"
-    "            command = \"link -o {{output}} {{ldflags}} @{{output}}.rsp\"\n"
-    "            rspfile = \"{{output}}.rsp\"\n"
-    "            rspfile_content = \"{{inputs}} {{solibs}} {{libs}}\"\n"
-    "          }\n"
-    "\n"
-    "    runtime_outputs  [string list with substitutions]\n"
-    "        Valid for: linker tools\n"
-    "\n"
-    "        If specified, this list is the subset of the outputs that should\n"
-    "        be added to runtime deps (see \"gn help runtime_deps\"). By\n"
-    "        default (if runtime_outputs is empty or unspecified), it will be\n"
-    "        the link_output.\n"
-    "\n"
-    "Expansions for tool variables\n"
-    "\n"
-    "  All paths are relative to the root build directory, which is the\n"
-    "  current directory for running all tools. These expansions are\n"
-    "  available to all tools:\n"
-    "\n"
-    "    {{label}}\n"
-    "        The label of the current target. This is typically used in the\n"
-    "        \"description\" field for link tools. The toolchain will be\n"
-    "        omitted from the label for targets in the default toolchain, and\n"
-    "        will be included for targets in other toolchains.\n"
-    "\n"
-    "    {{label_name}}\n"
-    "        The short name of the label of the target. This is the part\n"
-    "        after the colon. For \"//foo/bar:baz\" this will be \"baz\".\n"
-    "        Unlike {{target_output_name}}, this is not affected by the\n"
-    "        \"output_prefix\" in the tool or the \"output_name\" set\n"
-    "        on the target.\n"
-    "\n"
-    "    {{output}}\n"
-    "        The relative path and name of the output(s) of the current\n"
-    "        build step. If there is more than one output, this will expand\n"
-    "        to a list of all of them.\n"
-    "        Example: \"out/base/my_file.o\"\n"
-    "\n"
-    "    {{target_gen_dir}}\n"
-    "    {{target_out_dir}}\n"
-    "        The directory of the generated file and output directories,\n"
-    "        respectively, for the current target. There is no trailing\n"
-    "        slash. See also {{output_dir}} for linker tools.\n"
-    "        Example: \"out/base/test\"\n"
-    "\n"
-    "    {{target_output_name}}\n"
-    "        The short name of the current target with no path information,\n"
-    "        or the value of the \"output_name\" variable if one is specified\n"
-    "        in the target. This will include the \"output_prefix\" if any.\n"
-    "        See also {{label_name}}.\n"
-    "        Example: \"libfoo\" for the target named \"foo\" and an\n"
-    "        output prefix for the linker tool of \"lib\".\n"
-    "\n"
-    "  Compiler tools have the notion of a single input and a single output,\n"
-    "  along with a set of compiler-specific flags. The following expansions\n"
-    "  are available:\n"
-    "\n"
-    "    {{asmflags}}\n"
-    "    {{cflags}}\n"
-    "    {{cflags_c}}\n"
-    "    {{cflags_cc}}\n"
-    "    {{cflags_objc}}\n"
-    "    {{cflags_objcc}}\n"
-    "    {{defines}}\n"
-    "    {{include_dirs}}\n"
-    "        Strings correspond that to the processed flags/defines/include\n"
-    "        directories specified for the target.\n"
-    "        Example: \"--enable-foo --enable-bar\"\n"
-    "\n"
-    "        Defines will be prefixed by \"-D\" and include directories will\n"
-    "        be prefixed by \"-I\" (these work with Posix tools as well as\n"
-    "        Microsoft ones).\n"
-    "\n"
-    "    {{source}}\n"
-    "        The relative path and name of the current input file.\n"
-    "        Example: \"../../base/my_file.cc\"\n"
-    "\n"
-    "    {{source_file_part}}\n"
-    "        The file part of the source including the extension (with no\n"
-    "        directory information).\n"
-    "        Example: \"foo.cc\"\n"
-    "\n"
-    "    {{source_name_part}}\n"
-    "        The filename part of the source file with no directory or\n"
-    "        extension.\n"
-    "        Example: \"foo\"\n"
-    "\n"
-    "    {{source_gen_dir}}\n"
-    "    {{source_out_dir}}\n"
-    "        The directory in the generated file and output directories,\n"
-    "        respectively, for the current input file. If the source file\n"
-    "        is in the same directory as the target is declared in, they will\n"
-    "        will be the same as the \"target\" versions above.\n"
-    "        Example: \"gen/base/test\"\n"
-    "\n"
-    "  Linker tools have multiple inputs and (potentially) multiple outputs\n"
-    "  The static library tool (\"alink\") is not considered a linker tool.\n"
-    "  The following expansions are available:\n"
-    "\n"
-    "    {{inputs}}\n"
-    "    {{inputs_newline}}\n"
-    "        Expands to the inputs to the link step. This will be a list of\n"
-    "        object files and static libraries.\n"
-    "        Example: \"obj/foo.o obj/bar.o obj/somelibrary.a\"\n"
-    "\n"
-    "        The \"_newline\" version will separate the input files with\n"
-    "        newlines instead of spaces. This is useful in response files:\n"
-    "        some linkers can take a \"-filelist\" flag which expects newline\n"
-    "        separated files, and some Microsoft tools have a fixed-sized\n"
-    "        buffer for parsing each line of a response file.\n"
-    "\n"
-    "    {{ldflags}}\n"
-    "        Expands to the processed set of ldflags and library search paths\n"
-    "        specified for the target.\n"
-    "        Example: \"-m64 -fPIC -pthread -L/usr/local/mylib\"\n"
-    "\n"
-    "    {{libs}}\n"
-    "        Expands to the list of system libraries to link to. Each will\n"
-    "        be prefixed by the \"lib_prefix\".\n"
-    "\n"
-    "        As a special case to support Mac, libraries with names ending in\n"
-    "        \".framework\" will be added to the {{libs}} with \"-framework\"\n"
-    "        preceeding it, and the lib prefix will be ignored.\n"
-    "\n"
-    "        Example: \"-lfoo -lbar\"\n"
-    "\n"
-    "    {{output_dir}}\n"
-    "        The value of the \"output_dir\" variable in the target, or the\n"
-    "        the value of the \"default_output_dir\" value in the tool if the\n"
-    "        target does not override the output directory. This will be\n"
-    "        relative to the root_build_dir and will not end in a slash.\n"
-    "        Will be \".\" for output to the root_build_dir.\n"
-    "\n"
-    "        This is subtly different than {{target_out_dir}} which is\n"
-    "        defined by GN based on the target's path and not overridable.\n"
-    "        {{output_dir}} is for the final output, {{target_out_dir}} is\n"
-    "        generally for object files and other outputs.\n"
-    "\n"
-    "        Usually {{output_dir}} would be defined in terms of either\n"
-    "        {{target_out_dir}} or {{root_out_dir}}\n"
-    "\n"
-    "    {{output_extension}}\n"
-    "        The value of the \"output_extension\" variable in the target,\n"
-    "        or the value of the \"default_output_extension\" value in the\n"
-    "        tool if the target does not specify an output extension.\n"
-    "        Example: \".so\"\n"
-    "\n"
-    "    {{solibs}}\n"
-    "        Extra libraries from shared library dependencide not specified\n"
-    "        in the {{inputs}}. This is the list of link_output files from\n"
-    "        shared libraries (if the solink tool specifies a \"link_output\"\n"
-    "        variable separate from the \"depend_output\").\n"
-    "\n"
-    "        These should generally be treated the same as libs by your tool.\n"
-    "        Example: \"libfoo.so libbar.so\"\n"
-    "\n"
-    "  The static library (\"alink\") tool allows {{arflags}} plus the common\n"
-    "  tool substitutions.\n"
-    "\n"
-    "  The copy tool allows the common compiler/linker substitutions, plus\n"
-    "  {{source}} which is the source of the copy. The stamp tool allows\n"
-    "  only the common tool substitutions.\n"
-    "\n"
-    "  The copy_bundle_data and compile_xcassets tools only allows the common\n"
-    "  tool substitutions. Both tools are required to create iOS/OS X bundles\n"
-    "  and need only be defined on those platforms.\n"
-    "\n"
-    "  The copy_bundle_data tool will be called with one source and needs to\n"
-    "  copy (optionally optimizing the data representation) to its output. It\n"
-    "  may be called with a directory as input and it needs to be recursively\n"
-    "  copied.\n"
-    "\n"
-    "  The compile_xcassets tool will be called with one or more source (each\n"
-    "  an asset catalog) that needs to be compiled to a single output. The\n"
-    "  following substitutions are avaiable:\n"
-    "\n"
-    "    {{inputs}}\n"
-    "        Expands to the list of .xcassets to use as input to compile the\n"
-    "        asset catalog.\n"
-    "\n"
-    "    {{bundle_product_type}}\n"
-    "        Expands to the product_type of the bundle that will contain the\n"
-    "        compiled asset catalog. Usually corresponds to the product_type\n"
-    "        property of the corresponding create_bundle target.\n"
-    "\n"
-    "Separate linking and dependencies for shared libraries\n"
-    "\n"
-    "  Shared libraries are special in that not all changes to them require\n"
-    "  that dependent targets be re-linked. If the shared library is changed\n"
-    "  but no imports or exports are different, dependent code needn't be\n"
-    "  relinked, which can speed up the build.\n"
-    "\n"
-    "  If your link step can output a list of exports from a shared library\n"
-    "  and writes the file only if the new one is different, the timestamp of\n"
-    "  this file can be used for triggering re-links, while the actual shared\n"
-    "  library would be used for linking.\n"
-    "\n"
-    "  You will need to specify\n"
-    "    restat = true\n"
-    "  in the linker tool to make this work, so Ninja will detect if the\n"
-    "  timestamp of the dependency file has changed after linking (otherwise\n"
-    "  it will always assume that running a command updates the output):\n"
-    "\n"
-    "    tool(\"solink\") {\n"
-    "      command = \"...\"\n"
-    "      outputs = [\n"
-    "        \"{{output_dir}}/{{target_output_name}}{{output_extension}}\",\n"
-    "        \"{{output_dir}}/{{target_output_name}}"
-                 "{{output_extension}}.TOC\",\n"
-    "      ]\n"
-    "      link_output =\n"
-    "        \"{{output_dir}}/{{target_output_name}}{{output_extension}}\"\n"
-    "      depend_output =\n"
-    "        \"{{output_dir}}/{{target_output_name}}"
-                 "{{output_extension}}.TOC\"\n"
-    "      restat = true\n"
-    "    }\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  toolchain(\"my_toolchain\") {\n"
-    "    # Put these at the top to apply to all tools below.\n"
-    "    lib_prefix = \"-l\"\n"
-    "    lib_dir_prefix = \"-L\"\n"
-    "\n"
-    "    tool(\"cc\") {\n"
-    "      command = \"gcc {{source}} -o {{output}}\"\n"
-    "      outputs = [ \"{{source_out_dir}}/{{source_name_part}}.o\" ]\n"
-    "      description = \"GCC {{source}}\"\n"
-    "    }\n"
-    "    tool(\"cxx\") {\n"
-    "      command = \"g++ {{source}} -o {{output}}\"\n"
-    "      outputs = [ \"{{source_out_dir}}/{{source_name_part}}.o\" ]\n"
-    "      description = \"G++ {{source}}\"\n"
-    "    }\n"
-    "  }\n";
+    R"(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.
+
+    Platform specific tools:
+      "copy_bundle_data": [iOS, OS X] Tool to copy files in a bundle.
+      "compile_xcassets": [iOS, OS X] Tool to compile asset catalogs.
+
+Tool variables
+
+    command  [string with substitutions]
+        Valid for: all tools (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]
+
+        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 (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 (required when "rspfile" is specified)
+
+        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".
+
+)"  // String break to prevent overflowing the 16K max VC string length.
+R"(  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_prefix".
+
+        As a special case to support Mac, libraries with names ending in
+        ".framework" will be added to the {{libs}} with "-framework" preceeding
+        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 dependencide 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"
+
+)"  // String break to prevent overflowing the 16K max VC string length.
+R"(  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/OS X 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 avaiable:
+
+    {{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.
+
+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_prefix = "-l"
+    lib_dir_prefix = "-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}}"
+    }
+  };
+)";
 
 Value RunTool(Scope* scope,
               const FunctionCallNode* function,
diff --git a/tools/gn/function_toolchain_unittest.cc b/tools/gn/function_toolchain_unittest.cc
index c7ffbc7..2d8a548 100644
--- a/tools/gn/function_toolchain_unittest.cc
+++ b/tools/gn/function_toolchain_unittest.cc
@@ -14,12 +14,12 @@
   // These runtime outputs are a subset of the outputs so are OK.
   {
     TestParseInput input(
-        "toolchain(\"good\") {\n"
-        "  tool(\"link\") {\n"
-        "    outputs = [ \"foo\" ]\n"
-        "    runtime_outputs = [ \"foo\" ]\n"
-        "  }\n"
-        "}\n");
+        R"(toolchain("good") {
+          tool("link") {
+            outputs = [ "foo" ]
+            runtime_outputs = [ "foo" ]
+          }
+        })");
     ASSERT_FALSE(input.has_error());
 
     Err err;
@@ -43,12 +43,12 @@
   // This one is not a subset so should throw an error.
   {
     TestParseInput input(
-        "toolchain(\"bad\") {\n"
-        "  tool(\"link\") {\n"
-        "    outputs = [ \"foo\" ]\n"
-        "    runtime_outputs = [ \"bar\" ]\n"
-        "  }\n"
-        "}\n");
+        R"(toolchain("bad") {
+          tool("link") {
+            outputs = [ "foo" ]
+            runtime_outputs = [ "bar" ]
+          }
+        })");
     ASSERT_FALSE(input.has_error());
 
     Err err;
diff --git a/tools/gn/function_write_file.cc b/tools/gn/function_write_file.cc
index feb1004..0e2dd06 100644
--- a/tools/gn/function_write_file.cc
+++ b/tools/gn/function_write_file.cc
@@ -23,32 +23,32 @@
 const char kWriteFile_HelpShort[] =
     "write_file: Write a file to disk.";
 const char kWriteFile_Help[] =
-    "write_file: Write a file to disk.\n"
-    "\n"
-    "  write_file(filename, data)\n"
-    "\n"
-    "  If data is a list, the list will be written one-item-per-line with no\n"
-    "  quoting or brackets.\n"
-    "\n"
-    "  If the file exists and the contents are identical to that being\n"
-    "  written, the file will not be updated. This will prevent unnecessary\n"
-    "  rebuilds of targets that depend on this file.\n"
-    "\n"
-    "  One use for write_file is to write a list of inputs to an script\n"
-    "  that might be too long for the command line. However, it is\n"
-    "  preferrable to use response files for this purpose. See\n"
-    "  \"gn help response_file_contents\".\n"
-    "\n"
-    "  TODO(brettw) we probably need an optional third argument to control\n"
-    "  list formatting.\n"
-    "\n"
-    "Arguments\n"
-    "\n"
-    "  filename\n"
-    "      Filename to write. This must be within the output directory.\n"
-    "\n"
-    "  data:\n"
-    "      The list or string to write.\n";
+    R"(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 preferrable 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.
+)";
 
 Value RunWriteFile(Scope* scope,
                    const FunctionCallNode* function,
diff --git a/tools/gn/functions.cc b/tools/gn/functions.cc
index e584f87..e01a25c 100644
--- a/tools/gn/functions.cc
+++ b/tools/gn/functions.cc
@@ -181,17 +181,19 @@
 const char kAssert_HelpShort[] =
     "assert: Assert an expression is true at generation time.";
 const char kAssert_Help[] =
-    "assert: Assert an expression is true at generation time.\n"
-    "\n"
-    "  assert(<condition> [, <error string>])\n"
-    "\n"
-    "  If the condition is false, the build will fail with an error. If the\n"
-    "  optional second argument is provided, that string will be printed\n"
-    "  with the error message.\n"
-    "\n"
-    "Examples:\n"
-    "  assert(is_win)\n"
-    "  assert(defined(sources), \"Sources must be defined\")\n";
+    R"(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");
+)";
 
 Value RunAssert(Scope* scope,
                 const FunctionCallNode* function,
@@ -245,45 +247,47 @@
 const char kConfig_HelpShort[] =
     "config: Defines a configuration object.";
 const char kConfig_Help[] =
-    "config: Defines a configuration object.\n"
-    "\n"
-    "  Configuration objects can be applied to targets and specify sets of\n"
-    "  compiler flags, includes, defines, etc. They provide a way to\n"
-    "  conveniently group sets of this configuration information.\n"
-    "\n"
-    "  A config is referenced by its label just like a target.\n"
-    "\n"
-    "  The values in a config are additive only. If you want to remove a flag\n"
-    "  you need to remove the corresponding config that sets it. The final\n"
-    "  set of flags, defines, etc. for a target is generated in this order:\n"
-    "\n"
-    "   1. The values specified directly on the target (rather than using a\n"
-    "      config.\n"
-    "   2. The configs specified in the target's \"configs\" list, in order.\n"
-    "   3. Public_configs from a breadth-first traversal of the dependency\n"
-    "      tree in the order that the targets appear in \"deps\".\n"
-    "   4. All dependent configs from a breadth-first traversal of the\n"
-    "      dependency tree in the order that the targets appear in \"deps\".\n"
-    "\n"
-    "Variables valid in a config definition\n"
-    "\n"
+    R"(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
+)"
+
     CONFIG_VALUES_VARS_HELP
-    "  Nested configs: configs\n"
-    "\n"
-    "Variables on a target used to apply configs\n"
-    "\n"
-    "  all_dependent_configs, configs, public_configs\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  config(\"myconfig\") {\n"
-    "    includes = [ \"include/common\" ]\n"
-    "    defines = [ \"ENABLE_DOOM_MELON\" ]\n"
-    "  }\n"
-    "\n"
-    "  executable(\"mything\") {\n"
-    "    configs = [ \":myconfig\" ]\n"
-    "  }\n";
+
+R"(  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" ]
+  }
+)";
 
 Value RunConfig(const FunctionCallNode* function,
                 const std::vector<Value>& args,
@@ -342,64 +346,64 @@
 const char kDeclareArgs_HelpShort[] =
     "declare_args: Declare build arguments.";
 const char kDeclareArgs_Help[] =
-    "declare_args: Declare build arguments.\n"
-    "\n"
-    "  Introduces the given arguments into the current scope. If they are\n"
-    "  not specified on the command line or in a toolchain's arguments,\n"
-    "  the default values given in the declare_args block will be used.\n"
-    "  However, these defaults will not override command-line values.\n"
-    "\n"
-    "  See also \"gn help buildargs\" for an overview.\n"
-    "\n"
-    "  The precise behavior of declare args is:\n"
-    "\n"
-    "   1. The declare_arg block executes. Any variables in the enclosing\n"
-    "      scope are available for reading.\n"
-    "\n"
-    "   2. At the end of executing the block, any variables set within that\n"
-    "      scope are saved globally as build arguments, with their current\n"
-    "      values being saved as the \"default value\" for that argument.\n"
-    "\n"
-    "   3. User-defined overrides are applied. Anything set in \"gn args\"\n"
-    "      now overrides any default values. The resulting set of variables\n"
-    "      is promoted to be readable from the following code in the file.\n"
-    "\n"
-    "  This has some ramifications that may not be obvious:\n"
-    "\n"
-    "    - You should not perform difficult work inside a declare_args block\n"
-    "      since this only sets a default value that may be discarded. In\n"
-    "      particular, don't use the result of exec_script() to set the\n"
-    "      default value. If you want to have a script-defined default, set\n"
-    "      some default \"undefined\" value like [], \"\", or -1, and after\n"
-    "      the declare_args block, call exec_script if the value is unset by\n"
-    "      the user.\n"
-    "\n"
-    "    - Any code inside of the declare_args block will see the default\n"
-    "      values of previous variables defined in the block rather than\n"
-    "      the user-overridden value. This can be surprising because you will\n"
-    "      be used to seeing the overridden value. If you need to make the\n"
-    "      default value of one arg dependent on the possibly-overridden\n"
-    "      value of another, write two separate declare_args blocks:\n"
-    "\n"
-    "        declare_args() {\n"
-    "          enable_foo = true\n"
-    "        }\n"
-    "        declare_args() {\n"
-    "          # Bar defaults to same user-overridden state as foo.\n"
-    "          enable_bar = enable_foo\n"
-    "        }\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  declare_args() {\n"
-    "    enable_teleporter = true\n"
-    "    enable_doom_melon = false\n"
-    "  }\n"
-    "\n"
-    "  If you want to override the (default disabled) Doom Melon:\n"
-    "    gn --args=\"enable_doom_melon=true enable_teleporter=false\"\n"
-    "  This also sets the teleporter, but it's already defaulted to on so\n"
-    "  it will have no effect.\n";
+    R"(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_arg block executes. Any variables in the enclosing scope are
+      available for reading.
+
+   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.
+
+    - Any code inside of the declare_args block will see the default values of
+      previous variables defined in the block rather than the user-overridden
+      value. This can be surprising because you will be used to seeing the
+      overridden value. If you need to make the default value of one arg
+      dependent 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=false"
+  This also sets the teleporter, but it's already defaulted to on so it will
+  have no effect.
+)";
 
 Value RunDeclareArgs(Scope* scope,
                      const FunctionCallNode* function,
@@ -431,36 +435,37 @@
 const char kDefined_HelpShort[] =
     "defined: Returns whether an identifier is defined.";
 const char kDefined_Help[] =
-    "defined: Returns whether an identifier is defined.\n"
-    "\n"
-    "  Returns true if the given argument is defined. This is most useful in\n"
-    "  templates to assert that the caller set things up properly.\n"
-    "\n"
-    "  You can pass an identifier:\n"
-    "    defined(foo)\n"
-    "  which will return true or false depending on whether foo is defined in\n"
-    "  the current scope.\n"
-    "\n"
-    "  You can also check a named scope:\n"
-    "    defined(foo.bar)\n"
-    "  which will return true or false depending on whether bar is defined in\n"
-    "  the named scope foo. It will throw an error if foo is not defined or\n"
-    "  is not a scope.\n"
-    "\n"
-    "Example:\n"
-    "\n"
-    "  template(\"mytemplate\") {\n"
-    "    # To help users call this template properly...\n"
-    "    assert(defined(invoker.sources), \"Sources must be defined\")\n"
-    "\n"
-    "    # If we want to accept an optional \"values\" argument, we don't\n"
-    "    # want to dereference something that may not be defined.\n"
-    "    if (defined(invoker.values)) {\n"
-    "      values = invoker.values\n"
-    "    } else {\n"
-    "      values = \"some default value\"\n"
-    "    }\n"
-    "  }\n";
+    R"(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"
+    }
+  }
+)";
 
 Value RunDefined(Scope* scope,
                  const FunctionCallNode* function,
@@ -513,22 +518,23 @@
 const char kGetEnv_HelpShort[] =
     "getenv: Get an environment variable.";
 const char kGetEnv_Help[] =
-    "getenv: Get an environment variable.\n"
-    "\n"
-    "  value = getenv(env_var_name)\n"
-    "\n"
-    "  Returns the value of the given enironment variable. If the value is\n"
-    "  not found, it will try to look up the variable with the \"opposite\"\n"
-    "  case (based on the case of the first letter of the variable), but\n"
-    "  is otherwise case-sensitive.\n"
-    "\n"
-    "  If the environment variable is not found, the empty string will be\n"
-    "  returned. Note: it might be nice to extend this if we had the concept\n"
-    "  of \"none\" in the language to indicate lookup failure.\n"
-    "\n"
-    "Example:\n"
-    "\n"
-    "  home_dir = getenv(\"HOME\")\n";
+    R"(getenv: Get an environment variable.
+
+  value = getenv(env_var_name)
+
+  Returns the value of the given enironment 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")
+)";
 
 Value RunGetEnv(Scope* scope,
                 const FunctionCallNode* function,
@@ -551,38 +557,38 @@
 const char kImport_HelpShort[] =
     "import: Import a file into the current scope.";
 const char kImport_Help[] =
-    "import: Import a file into the current scope.\n"
-    "\n"
-    "  The import command loads the rules and variables resulting from\n"
-    "  executing the given file into the current scope.\n"
-    "\n"
-    "  By convention, imported files are named with a .gni extension.\n"
-    "\n"
-    "  An import is different than a C++ \"include\". The imported file is\n"
-    "  executed in a standalone environment from the caller of the import\n"
-    "  command. The results of this execution are cached for other files that\n"
-    "  import the same .gni file.\n"
-    "\n"
-    "  Note that you can not import a BUILD.gn file that's otherwise used\n"
-    "  in the build. Files must either be imported or implicitly loaded as\n"
-    "  a result of deps rules, but not both.\n"
-    "\n"
-    "  The imported file's scope will be merged with the scope at the point\n"
-    "  import was called. If there is a conflict (both the current scope and\n"
-    "  the imported file define some variable or rule with the same name but\n"
-    "  different value), a runtime error will be thrown. Therefore, it's good\n"
-    "  practice to minimize the stuff that an imported file defines.\n"
-    "\n"
-    "  Variables and templates beginning with an underscore '_' are\n"
-    "  considered private and will not be imported. Imported files can use\n"
-    "  such variables for internal computation without affecting other files.\n"
-    "\n"
-    "Examples:\n"
-    "\n"
-    "  import(\"//build/rules/idl_compilation_rule.gni\")\n"
-    "\n"
-    "  # Looks in the current directory.\n"
-    "  import(\"my_vars.gni\")\n";
+    R"(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")
+)";
 
 Value RunImport(Scope* scope,
                 const FunctionCallNode* function,
@@ -608,64 +614,63 @@
 const char kSetSourcesAssignmentFilter_HelpShort[] =
     "set_sources_assignment_filter: Set a pattern to filter source files.";
 const char kSetSourcesAssignmentFilter_Help[] =
-    "set_sources_assignment_filter: Set a pattern to filter source files.\n"
-    "\n"
-    "  The sources assignment filter is a list of patterns that remove files\n"
-    "  from the list implicitly whenever the \"sources\" variable is\n"
-    "  assigned to. This will do nothing for non-lists.\n"
-    "\n"
-    "  This is intended to be used to globally filter out files with\n"
-    "  platform-specific naming schemes when they don't apply, for example\n"
-    "  you may want to filter out all \"*_win.cc\" files on non-Windows\n"
-    "  platforms.\n"
-    "\n"
-    "  Typically this will be called once in the master build config script\n"
-    "  to set up the filter for the current platform. Subsequent calls will\n"
-    "  overwrite the previous values.\n"
-    "\n"
-    "  If you want to bypass the filter and add a file even if it might\n"
-    "  be filtered out, call set_sources_assignment_filter([]) to clear the\n"
-    "  list of filters. This will apply until the current scope exits\n"
-    "\n"
-    "How to use patterns\n"
-    "\n"
-    "  File patterns are VERY limited regular expressions. They must match\n"
-    "  the entire input string to be counted as a match. In regular\n"
-    "  expression parlance, there is an implicit \"^...$\" surrounding your\n"
-    "  input. If you want to match a substring, you need to use wildcards at\n"
-    "  the beginning and end.\n"
-    "\n"
-    "  There are only two special tokens understood by the pattern matcher.\n"
-    "  Everything else is a literal.\n"
-    "\n"
-    "   * Matches zero or more of any character. It does not depend on the\n"
-    "     preceding character (in regular expression parlance it is\n"
-    "     equivalent to \".*\").\n"
-    "\n"
-    "  \\b Matches a path boundary. This will match the beginning or end of\n"
-    "     a string, or a slash.\n"
-    "\n"
-    "Pattern examples\n"
-    "\n"
-    "  \"*asdf*\"\n"
-    "      Matches a string containing \"asdf\" anywhere.\n"
-    "\n"
-    "  \"asdf\"\n"
-    "      Matches only the exact string \"asdf\".\n"
-    "\n"
-    "  \"*.cc\"\n"
-    "      Matches strings ending in the literal \".cc\".\n"
-    "\n"
-    "  \"\\bwin/*\"\n"
-    "      Matches \"win/foo\" and \"foo/win/bar.cc\" but not \"iwin/foo\".\n"
-    "\n"
-    "Sources assignment example\n"
-    "\n"
-    "  # Filter out all _win files.\n"
-    "  set_sources_assignment_filter([ \"*_win.cc\", \"*_win.h\" ])\n"
-    "  sources = [ \"a.cc\", \"b_win.cc\" ]\n"
-    "  print(sources)\n"
-    "  # Will print [ \"a.cc\" ]. b_win one was filtered out.\n";
+    R"(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.
+)";
 
 Value RunSetSourcesAssignmentFilter(Scope* scope,
                                     const FunctionCallNode* function,
@@ -688,37 +693,38 @@
 const char kPool_HelpShort[] =
     "pool: Defines a pool object.";
 const char kPool_Help[] =
-    "pool: Defines a pool object.\n"
-    "\n"
-    "  Pool objects can be applied to a tool to limit the parallelism of the\n"
-    "  build. This object has a single property \"depth\" corresponding to\n"
-    "  the number of tasks that may run simultaneously.\n"
-    "\n"
-    "  As the file containing the pool definition may be executed in the\n"
-    "  context of more than one toolchain it is recommended to specify an\n"
-    "  explicit toolchain when defining and referencing a pool.\n"
-    "\n"
-    "  A pool is referenced by its label just like a target.\n"
-    "\n"
-    "Variables\n"
-    "\n"
-    "  depth*\n"
-    "  * = required\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  if (current_toolchain == default_toolchain) {\n"
-    "    pool(\"link_pool\") {\n"
-    "      depth = 1\n"
-    "    }\n"
-    "  }\n"
-    "\n"
-    "  toolchain(\"toolchain\") {\n"
-    "    tool(\"link\") {\n"
-    "      command = \"...\"\n"
-    "      pool = \":link_pool($default_toolchain)\")\n"
-    "    }\n"
-    "  }\n";
+    R"*(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)")
+    }
+  }
+)*";
 
 const char kDepth[] = "depth";
 
@@ -776,21 +782,23 @@
 const char kPrint_HelpShort[] =
     "print: Prints to the console.";
 const char kPrint_Help[] =
-    "print: Prints to the console.\n"
-    "\n"
-    "  Prints all arguments to the console separated by spaces. A newline is\n"
-    "  automatically appended to the end.\n"
-    "\n"
-    "  This function is intended for debugging. Note that build files are run\n"
-    "  in parallel so you may get interleaved prints. A buildfile may also\n"
-    "  be executed more than once in parallel in the context of different\n"
-    "  toolchains so the prints from one file may be duplicated or\n"
-    "  interleaved with itself.\n"
-    "\n"
-    "Examples:\n"
-    "  print(\"Hello world\")\n"
-    "\n"
-    "  print(sources, deps)\n";
+    R"(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)
+)";
 
 Value RunPrint(Scope* scope,
                const FunctionCallNode* function,
@@ -820,26 +828,26 @@
 const char kSplitList_HelpShort[] =
     "split_list: Splits a list into N different sub-lists.";
 const char kSplitList_Help[] =
-    "split_list: Splits a list into N different sub-lists.\n"
-    "\n"
-    "  result = split_list(input, n)\n"
-    "\n"
-    "  Given a list and a number N, splits the list into N sub-lists of\n"
-    "  approximately equal size. The return value is a list of the sub-lists.\n"
-    "  The result will always be a list of size N. If N is greater than the\n"
-    "  number of elements in the input, it will be padded with empty lists.\n"
-    "\n"
-    "  The expected use is to divide source files into smaller uniform\n"
-    "  chunks.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  The code:\n"
-    "    mylist = [1, 2, 3, 4, 5, 6]\n"
-    "    print(split_list(mylist, 3))\n"
-    "\n"
-    "  Will print:\n"
-    "    [[1, 2], [3, 4], [5, 6]\n";
+    R"(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]
+)";
 Value RunSplitList(Scope* scope,
                    const FunctionCallNode* function,
                    const ListNode* args_list,
diff --git a/tools/gn/functions_target.cc b/tools/gn/functions_target.cc
index b7ee6fb..fa97c86 100644
--- a/tools/gn/functions_target.cc
+++ b/tools/gn/functions_target.cc
@@ -88,68 +88,74 @@
 const char kAction_HelpShort[] =
     "action: Declare a target that runs a script a single time.";
 const char kAction_Help[] =
-    "action: Declare a target that runs a script a single time.\n"
-    "\n"
-    "  This target type allows you to run a script a single time to produce\n"
-    "  one or more output files. If you want to run a script once for each of\n"
-    "  a set of input files, see \"gn help action_foreach\".\n"
-    "\n"
-    "Inputs\n"
-    "\n"
-    "  In an action the \"sources\" and \"inputs\" are treated the same:\n"
-    "  they're both input dependencies on script execution with no special\n"
-    "  handling. If you want to pass the sources to your script, you must do\n"
-    "  so explicitly by including them in the \"args\". Note also that this\n"
-    "  means there is no special handling of paths since GN doesn't know\n"
-    "  which of the args are paths and not. You will want to use\n"
-    "  rebase_path() to convert paths to be relative to the root_build_dir.\n"
-    "\n"
-    "  You can dynamically write input dependencies (for incremental rebuilds\n"
-    "  if an input file changes) by writing a depfile when the script is run\n"
-    "  (see \"gn help depfile\"). This is more flexible than \"inputs\".\n"
-    "\n"
-    "  If the command line length is very long, you can use response files\n"
-    "  to pass args to your script. See \"gn help response_file_contents\".\n"
-    "\n"
-    "  It is recommended you put inputs to your script in the \"sources\"\n"
-    "  variable, and stuff like other Python files required to run your\n"
-    "  script in the \"inputs\" variable.\n"
-    "\n"
-    ACTION_DEPS
-    "\n"
-    "Outputs\n"
-    "\n"
-    "  You should specify files created by your script by specifying them in\n"
-    "  the \"outputs\".\n"
-    "\n"
-    SCRIPT_EXECUTION_CONTEXT
-    "\n"
-    "File name handling\n"
-    "\n"
-    SCRIPT_EXECUTION_OUTPUTS
-    "\n"
-    "Variables\n"
-    "\n"
-    "  args, console, data, data_deps, depfile, deps, inputs, outputs*,\n"
-    "  response_file_contents, script*, sources\n"
-    "  * = required\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  action(\"run_this_guy_once\") {\n"
-    "    script = \"doprocessing.py\"\n"
-    "    sources = [ \"my_configuration.txt\" ]\n"
-    "    outputs = [ \"$target_gen_dir/insightful_output.txt\" ]\n"
-    "\n"
-    "    # Our script imports this Python file so we want to rebuild if it\n"
-    "    # changes.\n"
-    "    inputs = [ \"helper_library.py\" ]\n"
-    "\n"
-    "    # Note that we have to manually pass the sources to our script if\n"
-    "    # the script needs them as inputs.\n"
-    "    args = [ \"--out\", rebase_path(target_gen_dir, root_build_dir) ] +\n"
-    "           rebase_path(sources, root_build_dir)\n"
-    "  }\n";
+    R"(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.
+)"
+
+  ACTION_DEPS
+
+R"(
+Outputs
+
+  You should specify files created by your script by specifying them in the
+  "outputs".
+)"
+
+  SCRIPT_EXECUTION_CONTEXT
+
+R"(
+File name handling
+)"
+
+  SCRIPT_EXECUTION_OUTPUTS
+
+R"(
+Variables
+
+  args, console, data, data_deps, depfile, deps, inputs, outputs*,
+  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)
+  }
+)";
 
 Value RunAction(Scope* scope,
                 const FunctionCallNode* function,
@@ -166,74 +172,74 @@
 const char kActionForEach_HelpShort[] =
     "action_foreach: Declare a target that runs a script over a set of files.";
 const char kActionForEach_Help[] =
-    "action_foreach: Declare a target that runs a script over a set of files.\n"
-    "\n"
-    "  This target type allows you to run a script once-per-file over a set\n"
-    "  of sources. If you want to run a script once that takes many files as\n"
-    "  input, see \"gn help action\".\n"
-    "\n"
-    "Inputs\n"
-    "\n"
-    "  The script will be run once per file in the \"sources\" variable. The\n"
-    "  \"outputs\" variable should specify one or more files with a source\n"
-    "  expansion pattern in it (see \"gn help source_expansion\"). The output\n"
-    "  file(s) for each script invocation should be unique. Normally you\n"
-    "  use \"{{source_name_part}}\" in each output file.\n"
-    "\n"
-    "  If your script takes additional data as input, such as a shared\n"
-    "  configuration file or a Python module it uses, those files should be\n"
-    "  listed in the \"inputs\" variable. These files are treated as\n"
-    "  dependencies of each script invocation.\n"
-    "\n"
-    "  If the command line length is very long, you can use response files\n"
-    "  to pass args to your script. See \"gn help response_file_contents\".\n"
-    "\n"
-    "  You can dynamically write input dependencies (for incremental rebuilds\n"
-    "  if an input file changes) by writing a depfile when the script is run\n"
-    "  (see \"gn help depfile\"). This is more flexible than \"inputs\".\n"
-    "\n"
-    ACTION_DEPS
-    "\n"
-    "Outputs\n"
-    "\n"
-    SCRIPT_EXECUTION_CONTEXT
-    "\n"
-    "File name handling\n"
-    "\n"
-    SCRIPT_EXECUTION_OUTPUTS
-    "\n"
-    "Variables\n"
-    "\n"
-    "  args, console, data, data_deps, depfile, deps, inputs, outputs*,\n"
-    "  response_file_contents, script*, sources*\n"
-    "  * = required\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  # Runs the script over each IDL file. The IDL script will generate\n"
-    "  # both a .cc and a .h file for each input.\n"
-    "  action_foreach(\"my_idl\") {\n"
-    "    script = \"idl_processor.py\"\n"
-    "    sources = [ \"foo.idl\", \"bar.idl\" ]\n"
-    "\n"
-    "    # Our script reads this file each time, so we need to list is as a\n"
-    "    # dependency so we can rebuild if it changes.\n"
-    "    inputs = [ \"my_configuration.txt\" ]\n"
-    "\n"
-    "    # Transformation from source file name to output file names.\n"
-    "    outputs = [ \"$target_gen_dir/{{source_name_part}}.h\",\n"
-    "                \"$target_gen_dir/{{source_name_part}}.cc\" ]\n"
-    "\n"
-    "    # Note that since \"args\" is opaque to GN, if you specify paths\n"
-    "    # here, you will need to convert it to be relative to the build\n"
-    "    # directory using \"rebase_path()\".\n"
-    "    args = [\n"
-    "      \"{{source}}\",\n"
-    "      \"-o\",\n"
-    "      rebase_path(relative_target_gen_dir, root_build_dir) +\n"
-    "        \"/{{source_name_part}}.h\" ]\n"
-    "  }\n"
-    "\n";
+    R"(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".
+)"
+  ACTION_DEPS
+R"(
+Outputs
+)"
+  SCRIPT_EXECUTION_CONTEXT
+R"(
+File name handling
+)"
+  SCRIPT_EXECUTION_OUTPUTS
+R"(
+Variables
+
+  args, console, data, data_deps, depfile, deps, inputs, outputs*,
+  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" ]
+  }
+)";
+
 Value RunActionForEach(Scope* scope,
                        const FunctionCallNode* function,
                        const std::vector<Value>& args,
@@ -249,55 +255,55 @@
 const char kBundleData_HelpShort[] =
     "bundle_data: [iOS/OS X] Declare a target without output.";
 const char kBundleData_Help[] =
-    "bundle_data: [iOS/OS X] Declare a target without output.\n"
-    "\n"
-    "  This target type allows to declare data that is required at runtime.\n"
-    "  It is used to inform \"create_bundle\" targets of the files to copy\n"
-    "  into generated bundle, see \"gn help create_bundle\" for help.\n"
-    "\n"
-    "  The target must define a list of files as \"sources\" and a single\n"
-    "  \"outputs\". If there are multiple files, source expansions must be\n"
-    "  used to express the output. The output must reference a file inside\n"
-    "  of {{bundle_root_dir}}.\n"
-    "\n"
-    "  This target can be used on all platforms though it is designed only to\n"
-    "  generate iOS/OS X bundle. In cross-platform projects, it is advised to\n"
-    "  put it behind iOS/Mac conditionals.\n"
-    "\n"
-    "  See \"gn help create_bundle\" for more information.\n"
-    "\n"
-    "Variables\n"
-    "\n"
-    "  sources*, outputs*, deps, data_deps, public_deps, visibility\n"
-    "  * = required\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  bundle_data(\"icudata\") {\n"
-    "    sources = [ \"sources/data/in/icudtl.dat\" ]\n"
-    "    outputs = [ \"{{bundle_resources_dir}}/{{source_file_part}}\" ]\n"
-    "  }\n"
-    "\n"
-    "  bundle_data(\"base_unittests_bundle_data]\") {\n"
-    "    sources = [ \"test/data\" ]\n"
-    "    outputs = [\n"
-    "      \"{{bundle_resources_dir}}/{{source_root_relative_dir}}/\" +\n"
-    "          \"{{source_file_part}}\"\n"
-    "    ]\n"
-    "  }\n"
-    "\n"
-    "  bundle_data(\"material_typography_bundle_data\") {\n"
-    "    sources = [\n"
-    "      \"src/MaterialTypography.bundle/Roboto-Bold.ttf\",\n"
-    "      \"src/MaterialTypography.bundle/Roboto-Italic.ttf\",\n"
-    "      \"src/MaterialTypography.bundle/Roboto-Regular.ttf\",\n"
-    "      \"src/MaterialTypography.bundle/Roboto-Thin.ttf\",\n"
-    "    ]\n"
-    "    outputs = [\n"
-    "      \"{{bundle_resources_dir}}/MaterialTypography.bundle/\"\n"
-    "          \"{{source_file_part}}\"\n"
-    "    ]\n"
-    "  }\n";
+    R"(bundle_data: [iOS/OS X] 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/OS X bundle. In cross-platform projects, it is advised to put it
+  behind iOS/Mac 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}}"
+    ]
+  }
+)";
 
 Value RunBundleData(Scope* scope,
                     const FunctionCallNode* function,
@@ -314,141 +320,142 @@
 const char kCreateBundle_HelpShort[] =
     "create_bundle: [iOS/OS X] Build an OS X / iOS bundle.";
 const char kCreateBundle_Help[] =
-    "create_bundle: [iOS/OS X] Build an OS X / iOS bundle.\n"
-    "\n"
-    "  This target generates an iOS/OS X bundle (which is a directory with a\n"
-    "  well-know structure). This target does not define any sources, instead\n"
-    "  they are computed from all \"bundle_data\" target this one depends on\n"
-    "  transitively (the recursion stops at \"create_bundle\" targets).\n"
-    "\n"
-    "  The \"bundle_*_dir\" properties must be defined. They will be used for\n"
-    "  the expansion of {{bundle_*_dir}} rules in \"bundle_data\" outputs.\n"
-    "\n"
-    "  This target can be used on all platforms though it is designed only to\n"
-    "  generate iOS/OS X bundle. In cross-platform projects, it is advised to\n"
-    "  put it behind iOS/Mac conditionals.\n"
-    "\n"
-    "  If a create_bundle is specified as a data_deps for another target, the\n"
-    "  bundle is considered a leaf, and its public and private dependencies\n"
-    "  will not contribute to any data or data_deps. Required runtime\n"
-    "  dependencies should be placed in the bundle. A create_bundle can\n"
-    "  declare its own explicit data and data_deps, however.\n"
-    "\n"
-    "Code signing\n"
-    "\n"
-    "  Some bundle needs to be code signed as part of the build (on iOS all\n"
-    "  application needs to be code signed to run on a device). The code\n"
-    "  signature can be configured via the code_signing_script variable.\n"
-    "\n"
-    "  If set, code_signing_script is the path of a script that invoked after\n"
-    "  all files have been moved into the bundle. The script must not change\n"
-    "  any file in the bundle, but may add new files.\n"
-    "\n"
-    "  If code_signing_script is defined, then code_signing_outputs must also\n"
-    "  be defined and non-empty to inform when the script needs to be re-run.\n"
-    "  The code_signing_args will be passed as is to the script (so path have\n"
-    "  to be rebased) and additional inputs may be listed with the variable\n"
-    "  code_signing_sources.\n"
-    "\n"
-    "Variables\n"
-    "\n"
-    "  bundle_root_dir*, bundle_resources_dir*, bundle_executable_dir*,\n"
-    "  bundle_plugins_dir*, bundle_deps_filter, deps, data_deps, public_deps,\n"
-    "  visibility, product_type, code_signing_args, code_signing_script,\n"
-    "  code_signing_sources, code_signing_outputs\n"
-    "  * = required\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  # Defines a template to create an application. On most platform, this\n"
-    "  # is just an alias for an \"executable\" target, but on iOS/OS X, it\n"
-    "  # builds an application bundle.\n"
-    "  template(\"app\") {\n"
-    "    if (!is_ios && !is_mac) {\n"
-    "      executable(target_name) {\n"
-    "        forward_variables_from(invoker, \"*\")\n"
-    "      }\n"
-    "    } else {\n"
-    "      app_name = target_name\n"
-    "      gen_path = target_gen_dir\n"
-    "\n"
-    "      action(\"${app_name}_generate_info_plist\") {\n"
-    "        script = [ \"//build/ios/ios_gen_plist.py\" ]\n"
-    "        sources = [ \"templates/Info.plist\" ]\n"
-    "        outputs = [ \"$gen_path/Info.plist\" ]\n"
-    "        args = rebase_path(sources, root_build_dir) +\n"
-    "               rebase_path(outputs, root_build_dir)\n"
-    "      }\n"
-    "\n"
-    "      bundle_data(\"${app_name}_bundle_info_plist\") {\n"
-    "        deps = [ \":${app_name}_generate_info_plist\" ]\n"
-    "        sources = [ \"$gen_path/Info.plist\" ]\n"
-    "        outputs = [ \"{{bundle_root_dir}}/Info.plist\" ]\n"
-    "      }\n"
-    "\n"
-    "      executable(\"${app_name}_generate_executable\") {\n"
-    "        forward_variables_from(invoker, \"*\", [\n"
-    "                                               \"output_name\",\n"
-    "                                               \"visibility\",\n"
-    "                                             ])\n"
-    "        output_name =\n"
-    "            rebase_path(\"$gen_path/$app_name\", root_build_dir)\n"
-    "      }\n"
-    "\n"
-    "      code_signing =\n"
-    "          defined(invoker.code_signing) && invoker.code_signing\n"
-    "\n"
-    "      if (is_ios && !code_signing) {\n"
-    "        bundle_data(\"${app_name}_bundle_executable\") {\n"
-    "          deps = [ \":${app_name}_generate_executable\" ]\n"
-    "          sources = [ \"$gen_path/$app_name\" ]\n"
-    "          outputs = [ \"{{bundle_executable_dir}}/$app_name\" ]\n"
-    "        }\n"
-    "      }\n"
-    "\n"
-    "      create_bundle(\"${app_name}.app\") {\n"
-    "        product_type = \"com.apple.product-type.application\"\n"
-    "        if (is_ios) {\n"
-    "          bundle_root_dir = \"${root_build_dir}/$target_name\"\n"
-    "          bundle_resources_dir = bundle_root_dir\n"
-    "          bundle_executable_dir = bundle_root_dir\n"
-    "          bundle_plugins_dir = bundle_root_dir + \"/Plugins\"\n"
-    "        } else {\n"
-    "          bundle_root_dir = \"${root_build_dir}/target_name/Contents\"\n"
-    "          bundle_resources_dir = bundle_root_dir + \"/Resources\"\n"
-    "          bundle_executable_dir = bundle_root_dir + \"/MacOS\"\n"
-    "          bundle_plugins_dir = bundle_root_dir + \"/Plugins\"\n"
-    "        }\n"
-    "        deps = [ \":${app_name}_bundle_info_plist\" ]\n"
-    "        if (is_ios && code_signing) {\n"
-    "          deps += [ \":${app_name}_generate_executable\" ]\n"
-    "          code_signing_script = \"//build/config/ios/codesign.py\"\n"
-    "          code_signing_sources = [\n"
-    "            invoker.entitlements_path,\n"
-    "            \"$target_gen_dir/$app_name\",\n"
-    "          ]\n"
-    "          code_signing_outputs = [\n"
-    "            \"$bundle_root_dir/$app_name\",\n"
-    "            \"$bundle_root_dir/_CodeSignature/CodeResources\",\n"
-    "            \"$bundle_root_dir/embedded.mobileprovision\",\n"
-    "            \"$target_gen_dir/$app_name.xcent\",\n"
-    "          ]\n"
-    "          code_signing_args = [\n"
-    "            \"-i=\" + ios_code_signing_identity,\n"
-    "            \"-b=\" + rebase_path(\n"
-    "                \"$target_gen_dir/$app_name\", root_build_dir),\n"
-    "            \"-e=\" + rebase_path(\n"
-    "                invoker.entitlements_path, root_build_dir),\n"
-    "            \"-e=\" + rebase_path(\n"
-    "                \"$target_gen_dir/$app_name.xcent\", root_build_dir),\n"
-    "            rebase_path(bundle_root_dir, root_build_dir),\n"
-    "          ]\n"
-    "        } else {\n"
-    "          deps += [ \":${app_name}_bundle_executable\" ]\n"
-    "        }\n"
-    "      }\n"
-    "    }\n"
-    "  }\n";
+    R"(create_bundle: [iOS/OS X] Build an OS X / iOS bundle.
+
+  This target generates an iOS/OS X 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/OS X bundle. In cross-platform projects, it is advised to put it
+  behind iOS/Mac 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_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
+  * = required
+
+Example
+
+  # Defines a template to create an application. On most platform, this is just
+  # an alias for an "executable" target, but on iOS/OS X, 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_root_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_resources_dir = bundle_root_dir
+          bundle_executable_dir = bundle_root_dir
+          bundle_plugins_dir = bundle_root_dir + "/Plugins"
+        } else {
+          bundle_root_dir = "${root_build_dir}/target_name/Contents"
+          bundle_resources_dir = bundle_root_dir + "/Resources"
+          bundle_executable_dir = bundle_root_dir + "/MacOS"
+          bundle_plugins_dir = bundle_root_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" ]
+        }
+      }
+    }
+  }
+)";
 
 Value RunCreateBundle(Scope* scope,
                       const FunctionCallNode* function,
@@ -465,44 +472,40 @@
 const char kCopy_HelpShort[] =
     "copy: Declare a target that copies files.";
 const char kCopy_Help[] =
-    "copy: Declare a target that copies files.\n"
-    "\n"
-    "File name handling\n"
-    "\n"
-    "  All output files must be inside the output directory of the build.\n"
-    "  You would generally use |$target_out_dir| or |$target_gen_dir| to\n"
-    "  reference the output or generated intermediate file directories,\n"
-    "  respectively.\n"
-    "\n"
-    "  Both \"sources\" and \"outputs\" must be specified. Sources can "
-    "include\n"
-    "  as many files as you want, but there can only be one item in the\n"
-    "  outputs list (plural is used for the name for consistency with\n"
-    "  other target types).\n"
-    "\n"
-    "  If there is more than one source file, your output name should specify\n"
-    "  a mapping from each source file to an output file name using source\n"
-    "  expansion (see \"gn help source_expansion\"). The placeholders will\n"
-    "  look like \"{{source_name_part}}\", for example.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  # Write a rule that copies a checked-in DLL to the output directory.\n"
-    "  copy(\"mydll\") {\n"
-    "    sources = [ \"mydll.dll\" ]\n"
-    "    outputs = [ \"$target_out_dir/mydll.dll\" ]\n"
-    "  }\n"
-    "\n"
-    "  # Write a rule to copy several files to the target generated files\n"
-    "  # directory.\n"
-    "  copy(\"myfiles\") {\n"
-    "    sources = [ \"data1.dat\", \"data2.dat\", \"data3.dat\" ]\n"
-    "\n"
-    "    # Use source expansion to generate output files with the\n"
-    "    # corresponding file names in the gen dir. This will just copy each\n"
-    "    # file.\n"
-    "    outputs = [ \"$target_gen_dir/{{source_file_part}}\" ]\n"
-    "  }\n";
+    R"(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}}" ]
+  }
+)";
 
 Value RunCopy(const FunctionCallNode* function,
               const std::vector<Value>& args,
@@ -521,10 +524,11 @@
 const char kExecutable_HelpShort[] =
     "executable: Declare an executable target.";
 const char kExecutable_Help[] =
-    "executable: Declare an executable target.\n"
-    "\n"
-    "Variables\n"
-    "\n"
+    R"(executable: Declare an executable target.
+
+Variables
+
+)"
     CONFIG_VALUES_VARS_HELP
     DEPS_VARS
     DEPENDENT_CONFIG_VARS
@@ -545,28 +549,28 @@
 const char kGroup_HelpShort[] =
     "group: Declare a named group of targets.";
 const char kGroup_Help[] =
-    "group: Declare a named group of targets.\n"
-    "\n"
-    "  This target type allows you to create meta-targets that just collect a\n"
-    "  set of dependencies into one named target. Groups can additionally\n"
-    "  specify configs that apply to their dependents.\n"
-    "\n"
-    "  Depending on a group is exactly like depending directly on that\n"
-    "  group's deps. \n"
-    "\n"
-    "Variables\n"
-    "\n"
+    R"(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_VARS
     DEPENDENT_CONFIG_VARS
-    "\n"
-    "Example\n"
-    "\n"
-    "  group(\"all\") {\n"
-    "    deps = [\n"
-    "      \"//project:runner\",\n"
-    "      \"//project:unit_tests\",\n"
-    "    ]\n"
-    "  }\n";
+
+R"(
+Example
+
+  group("all") {
+    deps = [
+      "//project:runner",
+      "//project:unit_tests",
+    ]
+  }
+)";
 
 Value RunGroup(Scope* scope,
                const FunctionCallNode* function,
@@ -583,18 +587,19 @@
 const char kLoadableModule_HelpShort[] =
     "loadable_module: Declare a loadable module target.";
 const char kLoadableModule_Help[] =
-    "loadable_module: Declare a loadable module target.\n"
-    "\n"
-    "  This target type allows you to create an object file that is (and can\n"
-    "  only be) loaded and unloaded at runtime.\n"
-    "\n"
-    "  A loadable module will be specified on the linker line for targets\n"
-    "  listing the loadable module in its \"deps\". If you don't want this\n"
-    "  (if you don't need to dynamically load the library at runtime), then\n"
-    "  you should use a \"shared_library\" target type instead.\n"
-    "\n"
-    "Variables\n"
-    "\n"
+    R"(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
+
+)"
     CONFIG_VALUES_VARS_HELP
     DEPS_VARS
     DEPENDENT_CONFIG_VARS
@@ -615,16 +620,17 @@
 const char kSharedLibrary_HelpShort[] =
     "shared_library: Declare a shared library target.";
 const char kSharedLibrary_Help[] =
-    "shared_library: Declare a shared library target.\n"
-    "\n"
-    "  A shared library will be specified on the linker line for targets\n"
-    "  listing the shared library in its \"deps\". If you don't want this\n"
-    "  (say you dynamically load the library at runtime), then you should\n"
-    "  depend on the shared library via \"data_deps\" or, on Darwin\n"
-    "  platforms, use a \"loadable_module\" target type instead.\n"
-    "\n"
-    "Variables\n"
-    "\n"
+    R"(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
+
+)"
     CONFIG_VALUES_VARS_HELP
     DEPS_VARS
     DEPENDENT_CONFIG_VARS
@@ -645,33 +651,32 @@
 extern const char kSourceSet_HelpShort[] =
     "source_set: Declare a source set target.";
 extern const char kSourceSet_Help[] =
-    "source_set: Declare a source set target.\n"
-    "\n"
-    "  A source set is a collection of sources that get compiled, but are not\n"
-    "  linked to produce any kind of library. Instead, the resulting object\n"
-    "  files are implicitly added to the linker line of all targets that\n"
-    "  depend on the source set.\n"
-    "\n"
-    "  In most cases, a source set will behave like a static library, except\n"
-    "  no actual library file will be produced. This will make the build go\n"
-    "  a little faster by skipping creation of a large static library, while\n"
-    "  maintaining the organizational benefits of focused build targets.\n"
-    "\n"
-    "  The main difference between a source set and a static library is\n"
-    "  around handling of exported symbols. Most linkers assume declaring\n"
-    "  a function exported means exported from the static library. The linker\n"
-    "  can then do dead code elimination to delete code not reachable from\n"
-    "  exported functions.\n"
-    "\n"
-    "  A source set will not do this code elimination since there is no link\n"
-    "  step. This allows you to link many sources sets into a shared library\n"
-    "  and have the \"exported symbol\" notation indicate \"export from the\n"
-    "  final shared library and not from the intermediate targets.\" There is\n"
-    "  no way to express this concept when linking multiple static libraries\n"
-    "  into a shared library.\n"
-    "\n"
-    "Variables\n"
-    "\n"
+    R"(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
+
+)"
     CONFIG_VALUES_VARS_HELP
     DEPS_VARS
     DEPENDENT_CONFIG_VARS
@@ -692,17 +697,18 @@
 const char kStaticLibrary_HelpShort[] =
     "static_library: Declare a static library target.";
 const char kStaticLibrary_Help[] =
-    "static_library: Declare a static library target.\n"
-    "\n"
-    "  Make a \".a\" / \".lib\" file.\n"
-    "\n"
-    "  If you only need the static library for intermediate results in the\n"
-    "  build, you should consider a source_set instead since it will skip\n"
-    "  the (potentially slow) step of creating the intermediate library file.\n"
-    "\n"
-    "Variables\n"
-    "\n"
-    "complete_static_lib\n"
+    R"(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
+)"
     CONFIG_VALUES_VARS_HELP
     DEPS_VARS
     DEPENDENT_CONFIG_VARS
@@ -723,34 +729,35 @@
 const char kTarget_HelpShort[] =
     "target: Declare an target with the given programmatic type.";
 const char kTarget_Help[] =
-    "target: Declare an target with the given programmatic type.\n"
-    "\n"
-    "  target(target_type_string, target_name_string) { ... }\n"
-    "\n"
-    "  The target() function is a way to invoke a built-in target or template\n"
-    "  with a type determined at runtime. This is useful for cases where the\n"
-    "  type of a target might not be known statically.\n"
-    "\n"
-    "  Only templates and built-in target functions are supported for the\n"
-    "  target_type_string parameter. Arbitrary functions, configs, and\n"
-    "  toolchains are not supported.\n"
-    "\n"
-    "  The call:\n"
-    "    target(\"source_set\", \"doom_melon\") {\n"
-    "  Is equivalent to:\n"
-    "    source_set(\"doom_melon\") {\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  if (foo_build_as_shared) {\n"
-    "    my_type = \"shared_library\"\n"
-    "  } else {\n"
-    "    my_type = \"source_set\"\n"
-    "  }\n"
-    "\n"
-    "  target(my_type, \"foo\") {\n"
-    "    ...\n"
-    "  }\n";
+    R"(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") {
+    ...
+  }
+)";
 Value RunTarget(Scope* scope,
                 const FunctionCallNode* function,
                 const std::vector<Value>& args,
diff --git a/tools/gn/functions_target_unittest.cc b/tools/gn/functions_target_unittest.cc
index f4eeb38..525bc7c 100644
--- a/tools/gn/functions_target_unittest.cc
+++ b/tools/gn/functions_target_unittest.cc
@@ -50,21 +50,21 @@
 
   // Test a good one first.
   TestParseInput good_input(
-      // Make a template with defaults set.
-      "template(\"my_templ\") {\n"
-      "  source_set(target_name) {\n"
-      "    forward_variables_from(invoker, \"*\")\n"
-      "  }\n"
-      "}\n"
-      "set_defaults(\"my_templ\") {\n"
-      "  default_value = 1\n"
-      "}\n"
+      R"(# Make a template with defaults set.
+      template("my_templ") {
+        source_set(target_name) {
+          forward_variables_from(invoker, "*")
+        }
+      }
+      set_defaults("my_templ") {
+        default_value = 1
+      }
 
-      // Invoke the template with target(). This will fail to execute if the
-      // defaults were not set properly, because "default_value" won't exist.
-      "target(\"my_templ\", \"foo\") {\n"
-      "  print(default_value)\n"
-      "}\n");
+      # Invoke the template with target(). This will fail to execute if the
+      # defaults were not set properly, because "default_value" won't exist.
+      target("my_templ", "foo") {
+        print(default_value)
+      })");
   ASSERT_FALSE(good_input.has_error());
   Err err;
   good_input.parsed()->Execute(setup.scope(), &err);
diff --git a/tools/gn/input_conversion.cc b/tools/gn/input_conversion.cc
index c14f4ae..d452759 100644
--- a/tools/gn/input_conversion.cc
+++ b/tools/gn/input_conversion.cc
@@ -147,57 +147,57 @@
 }  // namespace
 
 extern const char kInputConversion_Help[] =
-    "input_conversion: Specifies how to transform input to a variable.\n"
-    "\n"
-    "  input_conversion is an argument to read_file and exec_script that\n"
-    "  specifies how the result of the read operation should be converted\n"
-    "  into a variable.\n"
-    "\n"
-    "  \"\" (the default)\n"
-    "      Discard the result and return None.\n"
-    "\n"
-    "  \"list lines\"\n"
-    "      Return the file contents as a list, with a string for each line.\n"
-    "      The newlines will not be present in the result. The last line may\n"
-    "      or may not end in a newline.\n"
-    "\n"
-    "      After splitting, each individual line will be trimmed of\n"
-    "      whitespace on both ends.\n"
-    "\n"
-    "  \"scope\"\n"
-    "      Execute the block as GN code and return a scope with the\n"
-    "      resulting values in it. If the input was:\n"
-    "        a = [ \"hello.cc\", \"world.cc\" ]\n"
-    "        b = 26\n"
-    "      and you read the result into a variable named \"val\", then you\n"
-    "      could access contents the \".\" operator on \"val\":\n"
-    "        sources = val.a\n"
-    "        some_count = val.b\n"
-    "\n"
-    "  \"string\"\n"
-    "      Return the file contents into a single string.\n"
-    "\n"
-    "  \"value\"\n"
-    "      Parse the input as if it was a literal rvalue in a buildfile.\n"
-    "      Examples of typical program output using this mode:\n"
-    "        [ \"foo\", \"bar\" ]     (result will be a list)\n"
-    "      or\n"
-    "        \"foo bar\"            (result will be a string)\n"
-    "      or\n"
-    "        5                    (result will be an integer)\n"
-    "\n"
-    "      Note that if the input is empty, the result will be a null value\n"
-    "      which will produce an error if assigned to a variable.\n"
-    "\n"
-    "  \"trim ...\"\n"
-    "      Prefixing any of the other transformations with the word \"trim\"\n"
-    "      will result in whitespace being trimmed from the beginning and end\n"
-    "      of the result before processing.\n"
-    "\n"
-    "      Examples: \"trim string\" or \"trim list lines\"\n"
-    "\n"
-    "      Note that \"trim value\" is useless because the value parser skips\n"
-    "      whitespace anyway.\n";
+    R"(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.
+
+  "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.
+)";
 
 Value ConvertInputToValue(const Settings* settings,
                           const std::string& input,
diff --git a/tools/gn/label_pattern.cc b/tools/gn/label_pattern.cc
index a330b3b..5b8bf80 100644
--- a/tools/gn/label_pattern.cc
+++ b/tools/gn/label_pattern.cc
@@ -13,40 +13,40 @@
 #include "tools/gn/value.h"
 
 const char kLabelPattern_Help[] =
-    "Label patterns\n"
-    "\n"
-    "  A label pattern is a way of expressing one or more labels in a portion\n"
-    "  of the source tree. They are not general regular expressions.\n"
-    "\n"
-    "  They can take the following forms only:\n"
-    "\n"
-    "   - Explicit (no wildcard):\n"
-    "       \"//foo/bar:baz\"\n"
-    "       \":baz\"\n"
-    "\n"
-    "   - Wildcard target names:\n"
-    "       \"//foo/bar:*\" (all targets in the //foo/bar/BUILD.gn file)\n"
-    "       \":*\"  (all targets in the current build file)\n"
-    "\n"
-    "   - Wildcard directory names (\"*\" is only supported at the end)\n"
-    "       \"*\"  (all targets)\n"
-    "       \"//foo/bar/*\"  (all targets in any subdir of //foo/bar)\n"
-    "       \"./*\"  (all targets in the current build file or sub dirs)\n"
-    "\n"
-    "  Any of the above forms can additionally take an explicit toolchain.\n"
-    "  In this case, the toolchain must be fully qualified (no wildcards\n"
-    "  are supported in the toolchain name).\n"
-    "\n"
-    "    \"//foo:bar(//build/toochain:mac)\"\n"
-    "        An explicit target in an explicit toolchain.\n"
-    "\n"
-    "    \":*(//build/toolchain/linux:32bit)\"\n"
-    "        All targets in the current build file using the 32-bit Linux\n"
-    "        toolchain.\n"
-    "\n"
-    "    \"//foo/*(//build/toolchain:win)\"\n"
-    "        All targets in //foo and any subdirectory using the Windows\n"
-    "        toolchain.\n";
+    R"*(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.
+)*";
 
 LabelPattern::LabelPattern() : type_(MATCH) {
 }
diff --git a/tools/gn/parser.cc b/tools/gn/parser.cc
index 5fe9506..18e1ea1 100644
--- a/tools/gn/parser.cc
+++ b/tools/gn/parser.cc
@@ -13,210 +13,208 @@
 #include "tools/gn/token.h"
 
 const char kGrammar_Help[] =
-    "Language and grammar for GN build files\n"
-    "\n"
-    "Tokens\n"
-    "\n"
-    "  GN build files are read as sequences of tokens.  While splitting the\n"
-    "  file into tokens, the next token is the longest sequence of characters\n"
-    "  that form a valid token.\n"
-    "\n"
-    "White space and comments\n"
-    "\n"
-    "  White space is comprised of spaces (U+0020), horizontal tabs (U+0009),\n"
-    "  carriage returns (U+000D), and newlines (U+000A).\n"
-    "\n"
-    "  Comments start at the character \"#\" and stop at the next newline.\n"
-    "\n"
-    "  White space and comments are ignored except that they may separate\n"
-    "  tokens that would otherwise combine into a single token.\n"
-    "\n"
-    "Identifiers\n"
-    "\n"
-    "  Identifiers name variables and functions.\n"
-    "\n"
-    "      identifier = letter { letter | digit } .\n"
-    "      letter     = \"A\" ... \"Z\" | \"a\" ... \"z\" | \"_\" .\n"
-    "      digit      = \"0\" ... \"9\" .\n"
-    "\n"
-    "Keywords\n"
-    "\n"
-    "  The following keywords are reserved and may not be used as\n"
-    "  identifiers:\n"
-    "\n"
-    "          else    false   if      true\n"
-    "\n"
-    "Integer literals\n"
-    "\n"
-    "  An integer literal represents a decimal integer value.\n"
-    "\n"
-    "      integer = [ \"-\" ] digit { digit } .\n"
-    "\n"
-    "  Leading zeros and negative zero are disallowed.\n"
-    "\n"
-    "String literals\n"
-    "\n"
-    "  A string literal represents a string value consisting of the quoted\n"
-    "  characters with possible escape sequences and variable expansions.\n"
-    "\n"
-    "      string           = `\"` { char | escape | expansion } `\"` .\n"
-    "      escape           = `\\` ( \"$\" | `\"` | char ) .\n"
-    "      BracketExpansion = \"{\" ( identifier | ArrayAccess | ScopeAccess "
-                              ") \"}\" .\n"
-    "      Hex              = \"0x\" [0-9A-Fa-f][0-9A-Fa-f]\n"
-    "      expansion        = \"$\" ( identifier | BracketExpansion | Hex ) .\n"
-    "      char             = /* any character except \"$\", `\"`, or newline "
-                             "*/ .\n"
-    "\n"
-    "  After a backslash, certain sequences represent special characters:\n"
-    "\n"
-    "          \\\"    U+0022    quotation mark\n"
-    "          \\$    U+0024    dollar sign\n"
-    "          \\\\    U+005C    backslash\n"
-    "\n"
-    "  All other backslashes represent themselves.\n"
-    "\n"
-    "  To insert an arbitrary byte value, use $0xFF. For example, to\n"
-    "  insert a newline character: \"Line one$0x0ALine two\".\n"
-    "\n"
-    "  An expansion will evaluate the variable following the '$' and insert\n"
-    "  a stringified version of it into the result. For example, to concat\n"
-    "  two path components with a slash separating them:\n"
-    "    \"$var_one/$var_two\"\n"
-    "  Use the \"${var_one}\" format to be explicitly deliniate the variable\n"
-    "  for otherwise-ambiguous cases.\n"
-    "\n"
-    "Punctuation\n"
-    "\n"
-    "  The following character sequences represent punctuation:\n"
-    "\n"
-    "          +       +=      ==      !=      (       )\n"
-    "          -       -=      <       <=      [       ]\n"
-    "          !       =       >       >=      {       }\n"
-    "                          &&      ||      .       ,\n"
-    "\n"
-    "Grammar\n"
-    "\n"
-    "  The input tokens form a syntax tree following a context-free grammar:\n"
-    "\n"
-    "      File = StatementList .\n"
-    "\n"
-    "      Statement     = Assignment | Call | Condition .\n"
-    "      LValue        = identifier | ArrayAccess | ScopeAccess .\n"
-    "      Assignment    = LValue AssignOp Expr .\n"
-    "      Call          = identifier \"(\" [ ExprList ] \")\" [ Block ] .\n"
-    "      Condition     = \"if\" \"(\" Expr \")\" Block\n"
-    "                      [ \"else\" ( Condition | Block ) ] .\n"
-    "      Block         = \"{\" StatementList \"}\" .\n"
-    "      StatementList = { Statement } .\n"
-    "\n"
-    "      ArrayAccess = identifier \"[\" Expr \"]\" .\n"
-    "      ScopeAccess = identifier \".\" identifier .\n"
-    "      Expr        = UnaryExpr | Expr BinaryOp Expr .\n"
-    "      UnaryExpr   = PrimaryExpr | UnaryOp UnaryExpr .\n"
-    "      PrimaryExpr = identifier | integer | string | Call\n"
-    "                  | ArrayAccess | ScopeAccess | Block\n"
-    "                  | \"(\" Expr \")\"\n"
-    "                  | \"[\" [ ExprList [ \",\" ] ] \"]\" .\n"
-    "      ExprList    = Expr { \",\" Expr } .\n"
-    "\n"
-    "      AssignOp = \"=\" | \"+=\" | \"-=\" .\n"
-    "      UnaryOp  = \"!\" .\n"
-    "      BinaryOp = \"+\" | \"-\"                  // highest priority\n"
-    "               | \"<\" | \"<=\" | \">\" | \">=\"\n"
-    "               | \"==\" | \"!=\"\n"
-    "               | \"&&\"\n"
-    "               | \"||\" .                     // lowest priority\n"
-    "\n"
-    "  All binary operators are left-associative.\n"
-    "\n"
-    "Types\n"
-    "\n"
-    "  The GN language is dynamically typed. The following types are used:\n"
-    "\n"
-    "   - Boolean: Uses the keywords \"true\" and \"false\". There is no\n"
-    "     implicit conversion between booleans and integers.\n"
-    "\n"
-    "   - Integers: All numbers in GN are signed 64-bit integers.\n"
-    "\n"
-    "   - Strings: Strings are 8-bit with no enforced encoding. When a string\n"
-    "     is used to interact with other systems with particular encodings\n"
-    "     (like the Windows and Mac filesystems) it is assumed to be UTF-8.\n"
-    "     See \"String literals\" above for more.\n"
-    "\n"
-    "   - Lists: Lists are arbitrary-length ordered lists of values. See\n"
-    "     \"Lists\" below for more.\n"
-    "\n"
-    "   - Scopes: Scopes are like dictionaries that use variable names for\n"
-    "     keys. See \"Scopes\" below for more.\n"
-    "\n"
-    "Lists\n"
-    "\n"
-    "  Lists are created with [] and using commas to separate items:\n"
-    "\n"
-    "       mylist = [ 0, 1, 2, \"some string\" ]\n"
-    "\n"
-    "  A comma after the last item is optional. Lists are dereferenced using\n"
-    "  0-based indexing:\n"
-    "\n"
-    "       mylist[0] += 1\n"
-    "       var = mylist[2]\n"
-    "\n"
-    "  Lists can be concatenated using the '+' and '+=' operators. Bare\n"
-    "  values can not be concatenated with lists, to add a single item,\n"
-    "  it must be put into a list of length one.\n"
-    "\n"
-    "  Items can be removed from lists using the '-' and '-=' operators.\n"
-    "  This will remove all occurrences of every item in the right-hand list\n"
-    "  from the left-hand list. It is an error to remove an item not in the\n"
-    "  list. This is to prevent common typos and to detect dead code that\n"
-    "  is removing things that no longer apply.\n"
-    "\n"
-    "  It is an error to use '=' to replace a nonempty list with another\n"
-    "  nonempty list. This is to prevent accidentally overwriting data\n"
-    "  when in most cases '+=' was intended. To overwrite a list on purpose,\n"
-    "  first assign it to the empty list:\n"
-    "\n"
-    "    mylist = []\n"
-    "    mylist = otherlist\n"
-    "\n"
-    "  When assigning to a list named 'sources' using '=' or '+=', list\n"
-    "  items may be automatically filtered out.\n"
-    "  See \"gn help set_sources_assignment_filter\" for more.\n"
-    "\n"
-    "Scopes\n"
-    "\n"
-    "  All execution happens in the context of a scope which holds the\n"
-    "  current state (like variables). With the exception of loops and\n"
-    "  conditions, '{' introduces a new scope that has a parent reference to\n"
-    "  the old scope.\n"
-    "\n"
-    "  Variable reads recursively search all nested scopes until the\n"
-    "  variable is found or there are no more scopes. Variable writes always\n"
-    "  go into the current scope. This means that after the closing '}'\n"
-    "  (again excepting loops and conditions), all local variables will be\n"
-    "  restored to the previous values. This also means that \"foo = foo\"\n"
-    "  can do useful work by copying a variable into the current scope that\n"
-    "  was defined in a containing scope.\n"
-    "\n"
-    "  Scopes can also be assigned to variables. Such scopes can be created\n"
-    "  by functions like exec_script, when invoking a template (the template\n"
-    "  code refers to the variables set by the invoking code by the\n"
-    "  implicitly-created \"invoker\" scope), or explicitly like:\n"
-    "\n"
-    "    empty_scope = {}\n"
-    "    myvalues = {\n"
-    "      foo = 21\n"
-    "      bar = \"something\"\n"
-    "    }\n"
-    "\n"
-    "  Inside such a scope definition can be any GN code including\n"
-    "  conditionals and function calls. After the close of the scope, it will\n"
-    "  contain all variables explicitly set by the code contained inside it.\n"
-    "  After this, the values can be read, modified, or added to:\n"
-    "\n"
-    "    myvalues.foo += 2\n"
-    "    empty_scope.new_thing = [ 1, 2, 3 ]\n";
+    R"*(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 ]
+)*";
 
 enum Precedence {
   PRECEDENCE_ASSIGNMENT = 1,  // Lowest precedence.
diff --git a/tools/gn/runtime_deps.cc b/tools/gn/runtime_deps.cc
index 1849117..14e13e3 100644
--- a/tools/gn/runtime_deps.cc
+++ b/tools/gn/runtime_deps.cc
@@ -204,72 +204,73 @@
 }  // namespace
 
 const char kRuntimeDeps_Help[] =
-    "Runtime dependencies\n"
-    "\n"
-    "  Runtime dependencies of a target are exposed via the \"runtime_deps\"\n"
-    "  category of \"gn desc\" (see \"gn help desc\") or they can be written\n"
-    "  at build generation time via write_runtime_deps(), or\n"
-    "  --runtime-deps-list-file (see \"gn help --runtime-deps-list-file\").\n"
-    "\n"
-    "  To a first approximation, the runtime dependencies of a target are\n"
-    "  the set of \"data\" files, data directories, and the shared libraries\n"
-    "  from all transitive dependencies. Executables, shared libraries, and\n"
-    "  loadable modules are considered runtime dependencies of themselves.\n"
-    "\n"
-    "Executables\n"
-    "\n"
-    "  Executable targets and those executable targets' transitive\n"
-    "  dependencies are not considered unless that executable is listed in\n"
-    "  \"data_deps\". Otherwise, GN assumes that the executable (and\n"
-    "  everything it requires) is a build-time dependency only.\n"
-    "\n"
-    "Actions and copies\n"
-    "\n"
-    "  Action and copy targets that are listed as \"data_deps\" will have all\n"
-    "  of their outputs and data files considered as runtime dependencies.\n"
-    "  Action and copy targets that are \"deps\" or \"public_deps\" will have\n"
-    "  only their data files considered as runtime dependencies. These\n"
-    "  targets can list an output file in both the \"outputs\" and \"data\"\n"
-    "  lists to force an output file as a runtime dependency in all cases.\n"
-    "\n"
-    "  The different rules for deps and data_deps are to express build-time\n"
-    "  (deps) vs. run-time (data_deps) outputs. If GN counted all build-time\n"
-    "  copy steps as data dependencies, there would be a lot of extra stuff,\n"
-    "  and if GN counted all run-time dependencies as regular deps, the\n"
-    "  build's parallelism would be unnecessarily constrained.\n"
-    "\n"
-    "  This rule can sometimes lead to unintuitive results. For example,\n"
-    "  given the three targets:\n"
-    "    A  --[data_deps]-->  B  --[deps]-->  ACTION\n"
-    "  GN would say that A does not have runtime deps on the result of the\n"
-    "  ACTION, which is often correct. But the purpose of the B target might\n"
-    "  be to collect many actions into one logic unit, and the \"data\"-ness\n"
-    "  of A's dependency is lost. Solutions:\n"
-    "\n"
-    "   - List the outputs of the action in it's data section (if the\n"
-    "     results of that action are always runtime files).\n"
-    "   - Have B list the action in data_deps (if the outputs of the actions\n"
-    "     are always runtime files).\n"
-    "   - Have B list the action in both deps and data deps (if the outputs\n"
-    "     might be used in both contexts and you don't care about unnecessary\n"
-    "     entries in the list of files required at runtime).\n"
-    "   - Split B into run-time and build-time versions with the appropriate\n"
-    "     \"deps\" for each.\n"
-    "\n"
-    "Static libraries and source sets\n"
-    "\n"
-    "  The results of static_library or source_set targets are not considered\n"
-    "  runtime dependencies since these are assumed to be intermediate\n"
-    "  targets only. If you need to list a static library as a runtime\n"
-    "  dependency, you can manually compute the .a/.lib file name for the\n"
-    "  current platform and list it in the \"data\" list of a target\n"
-    "  (possibly on the static library target itself).\n"
-    "\n"
-    "Multiple outputs\n"
-    "\n"
-    "  Linker tools can specify which of their outputs should be considered\n"
-    "  when computing the runtime deps by setting runtime_outputs. If this\n"
-    "  is unset on the tool, the default will be the first output only.\n";
+    R"(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 it's 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.
+)";
 
 RuntimeDepsVector ComputeRuntimeDeps(const Target* target) {
   RuntimeDepsVector result;
diff --git a/tools/gn/setup.cc b/tools/gn/setup.cc
index 240c11f..c5eace2 100644
--- a/tools/gn/setup.cc
+++ b/tools/gn/setup.cc
@@ -41,87 +41,84 @@
 #endif
 
 extern const char kDotfile_Help[] =
-    ".gn file\n"
-    "\n"
-    "  When gn starts, it will search the current directory and parent\n"
-    "  directories for a file called \".gn\". This indicates the source root.\n"
-    "  You can override this detection by using the --root command-line\n"
-    "  argument\n"
-    "\n"
-    "  The .gn file in the source root will be executed. The syntax is the\n"
-    "  same as a buildfile, but with very limited build setup-specific\n"
-    "  meaning.\n"
-    "\n"
-    "  If you specify --root, by default GN will look for the file .gn in\n"
-    "  that directory. If you want to specify a different file, you can\n"
-    "  additionally pass --dotfile:\n"
-    "\n"
-    "    gn gen out/Debug --root=/home/build --dotfile=/home/my_gn_file.gn\n"
-    "\n"
-    "Variables\n"
-    "\n"
-    "  buildconfig [required]\n"
-    "      Label of the build config file. This file will be used to set up\n"
-    "      the build file execution environment for each toolchain.\n"
-    "\n"
-    "  check_targets [optional]\n"
-    "      A list of labels and label patterns that should be checked when\n"
-    "      running \"gn check\" or \"gn gen --check\". If unspecified, all\n"
-    "      targets will be checked. If it is the empty list, no targets will\n"
-    "      be checked.\n"
-    "\n"
-    "      The format of this list is identical to that of \"visibility\"\n"
-    "      so see \"gn help visibility\" for examples.\n"
-    "\n"
-    "  exec_script_whitelist [optional]\n"
-    "      A list of .gn/.gni files (not labels) that have permission to call\n"
-    "      the exec_script function. If this list is defined, calls to\n"
-    "      exec_script will be checked against this list and GN will fail if\n"
-    "      the current file isn't in the list.\n"
-    "\n"
-    "      This is to allow the use of exec_script to be restricted since\n"
-    "      is easy to use inappropriately. Wildcards are not supported.\n"
-    "      Files in the secondary_source tree (if defined) should be\n"
-    "      referenced by ignoring the secondary tree and naming them as if\n"
-    "      they are in the main tree.\n"
-    "\n"
-    "      If unspecified, the ability to call exec_script is unrestricted.\n"
-    "\n"
-    "      Example:\n"
-    "        exec_script_whitelist = [\n"
-    "          \"//base/BUILD.gn\",\n"
-    "          \"//build/my_config.gni\",\n"
-    "        ]\n"
-    "\n"
-    "  root [optional]\n"
-    "      Label of the root build target. The GN build will start by loading\n"
-    "      the build file containing this target name. This defaults to\n"
-    "      \"//:\" which will cause the file //BUILD.gn to be loaded.\n"
-    "\n"
-    "  secondary_source [optional]\n"
-    "      Label of an alternate directory tree to find input files. When\n"
-    "      searching for a BUILD.gn file (or the build config file discussed\n"
-    "      above), the file will first be looked for in the source root.\n"
-    "      If it's not found, the secondary source root will be checked\n"
-    "      (which would contain a parallel directory hierarchy).\n"
-    "\n"
-    "      This behavior is intended to be used when BUILD.gn files can't be\n"
-    "      checked in to certain source directories for whatever reason.\n"
-    "\n"
-    "      The secondary source root must be inside the main source tree.\n"
-    "\n"
-    "Example .gn file contents\n"
-    "\n"
-    "  buildconfig = \"//build/config/BUILDCONFIG.gn\"\n"
-    "\n"
-    "  check_targets = [\n"
-    "    \"//doom_melon/*\",  # Check everything in this subtree.\n"
-    "    \"//tools:mind_controlling_ant\",  # Check this specific target.\n"
-    "  ]\n"
-    "\n"
-    "  root = \"//:root\"\n"
-    "\n"
-    "  secondary_source = \"//build/config/temporary_buildfiles/\"\n";
+    R"(.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
+
+  buildconfig [required]
+      Label of 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.
+
+  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.
+
+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/"
+)";
 
 namespace {
 
diff --git a/tools/gn/substitution_writer.cc b/tools/gn/substitution_writer.cc
index ce57485..4d818cd 100644
--- a/tools/gn/substitution_writer.cc
+++ b/tools/gn/substitution_writer.cc
@@ -34,113 +34,106 @@
 }  // namespace
 
 const char kSourceExpansion_Help[] =
-    "How Source Expansion Works\n"
-    "\n"
-    "  Source expansion is used for the action_foreach and copy target types\n"
-    "  to map source file names to output file names or arguments.\n"
-    "\n"
-    "  To perform source expansion in the outputs, GN maps every entry in the\n"
-    "  sources to every entry in the outputs list, producing the cross\n"
-    "  product of all combinations, expanding placeholders (see below).\n"
-    "\n"
-    "  Source expansion in the args works similarly, but performing the\n"
-    "  placeholder substitution produces a different set of arguments for\n"
-    "  each invocation of the script.\n"
-    "\n"
-    "  If no placeholders are found, the outputs or args list will be treated\n"
-    "  as a static list of literal file names that do not depend on the\n"
-    "  sources.\n"
-    "\n"
-    "  See \"gn help copy\" and \"gn help action_foreach\" for more on how\n"
-    "  this is applied.\n"
-    "\n"
-    "Placeholders\n"
-    "\n"
-    "  This section discusses only placeholders for actions. There are other\n"
-    "  placeholders used in the definition of tools. See \"gn help tool\" for\n"
-    "  those.\n"
-    "\n"
-    "  {{source}}\n"
-    "      The name of the source file including directory (*). This will\n"
-    "      generally be used for specifying inputs to a script in the\n"
-    "      \"args\" variable.\n"
-    "        \"//foo/bar/baz.txt\" => \"../../foo/bar/baz.txt\"\n"
-    "\n"
-    "  {{source_file_part}}\n"
-    "      The file part of the source including the extension.\n"
-    "        \"//foo/bar/baz.txt\" => \"baz.txt\"\n"
-    "\n"
-    "  {{source_name_part}}\n"
-    "      The filename part of the source file with no directory or\n"
-    "      extension. This will generally be used for specifying a\n"
-    "      transformation from a source file to a destination file with the\n"
-    "      same name but different extension.\n"
-    "        \"//foo/bar/baz.txt\" => \"baz\"\n"
-    "\n"
-    "  {{source_dir}}\n"
-    "      The directory (*) containing the source file with no\n"
-    "      trailing slash.\n"
-    "        \"//foo/bar/baz.txt\" => \"../../foo/bar\"\n"
-    "\n"
-    "  {{source_root_relative_dir}}\n"
-    "      The path to the source file's directory relative to the source\n"
-    "      root, with no leading \"//\" or trailing slashes. If the path is\n"
-    "      system-absolute, (beginning in a single slash) this will just\n"
-    "      return the path with no trailing slash. This value will always\n"
-    "      be the same, regardless of whether it appears in the \"outputs\"\n"
-    "      or \"args\" section.\n"
-    "        \"//foo/bar/baz.txt\" => \"foo/bar\"\n"
-    "\n"
-    "  {{source_gen_dir}}\n"
-    "      The generated file directory (*) corresponding to the source\n"
-    "      file's path. This will be different than the target's generated\n"
-    "      file directory if the source file is in a different directory\n"
-    "      than the BUILD.gn file.\n"
-    "        \"//foo/bar/baz.txt\" => \"gen/foo/bar\"\n"
-    "\n"
-    "  {{source_out_dir}}\n"
-    "      The object file directory (*) corresponding to the source file's\n"
-    "      path, relative to the build directory. this us be different than\n"
-    "      the target's out directory if the source file is in a different\n"
-    "      directory than the build.gn file.\n"
-    "        \"//foo/bar/baz.txt\" => \"obj/foo/bar\"\n"
-    "\n"
-    "(*) Note on directories\n"
-    "\n"
-    "  Paths containing directories (except the source_root_relative_dir)\n"
-    "  will be different depending on what context the expansion is evaluated\n"
-    "  in. Generally it should \"just work\" but it means you can't\n"
-    "  concatenate strings containing these values with reasonable results.\n"
-    "\n"
-    "  Details: source expansions can be used in the \"outputs\" variable,\n"
-    "  the \"args\" variable, and in calls to \"process_file_template\". The\n"
-    "  \"args\" are passed to a script which is run from the build directory,\n"
-    "  so these directories will relative to the build directory for the\n"
-    "  script to find. In the other cases, the directories will be source-\n"
-    "  absolute (begin with a \"//\") because the results of those expansions\n"
-    "  will be handled by GN internally.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  Non-varying outputs:\n"
-    "    action(\"hardcoded_outputs\") {\n"
-    "      sources = [ \"input1.idl\", \"input2.idl\" ]\n"
-    "      outputs = [ \"$target_out_dir/output1.dat\",\n"
-    "                  \"$target_out_dir/output2.dat\" ]\n"
-    "    }\n"
-    "  The outputs in this case will be the two literal files given.\n"
-    "\n"
-    "  Varying outputs:\n"
-    "    action_foreach(\"varying_outputs\") {\n"
-    "      sources = [ \"input1.idl\", \"input2.idl\" ]\n"
-    "      outputs = [ \"{{source_gen_dir}}/{{source_name_part}}.h\",\n"
-    "                  \"{{source_gen_dir}}/{{source_name_part}}.cc\" ]\n"
-    "    }\n"
-    "  Performing source expansion will result in the following output names:\n"
-    "    //out/Debug/obj/mydirectory/input1.h\n"
-    "    //out/Debug/obj/mydirectory/input1.cc\n"
-    "    //out/Debug/obj/mydirectory/input2.h\n"
-    "    //out/Debug/obj/mydirectory/input2.cc\n";
+    R"(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"
+
+(*) 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
+)";
 
 // static
 void SubstitutionWriter::WriteWithNinjaVariables(
diff --git a/tools/gn/switches.cc b/tools/gn/switches.cc
index 8884634..05c2a5b 100644
--- a/tools/gn/switches.cc
+++ b/tools/gn/switches.cc
@@ -10,34 +10,34 @@
 const char kArgs_HelpShort[] =
     "--args: Specifies build arguments overrides.";
 const char kArgs_Help[] =
-    "--args: Specifies build arguments overrides.\n"
-    "\n"
-    "  See \"gn help buildargs\" for an overview of how build arguments work.\n"
-    "\n"
-    "  Most operations take a build directory. The build arguments are taken\n"
-    "  from the previous build done in that directory. If a command specifies\n"
-    "  --args, it will override the previous arguments stored in the build\n"
-    "  directory, and use the specified ones.\n"
-    "\n"
-    "  The args specified will be saved to the build directory for subsequent\n"
-    "  commands. Specifying --args=\"\" will clear all build arguments.\n"
-    "\n"
-    "Formatting\n"
-    "\n"
-    "  The value of the switch is interpreted in GN syntax. For typical usage\n"
-    "  of string arguments, you will need to be careful about escaping of\n"
-    "  quotes.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gn gen out/Default --args=\"foo=\\\"bar\\\"\"\n"
-    "\n"
-    "  gn gen out/Default --args='foo=\"bar\" enable=true blah=7'\n"
-    "\n"
-    "  gn check out/Default --args=\"\"\n"
-    "    Clears existing build args from the directory.\n"
-    "\n"
-    "  gn desc out/Default --args=\"some_list=[1, false, \\\"foo\\\"]\"\n";
+    R"(--args: Specifies build arguments overrides.
+
+  See "gn help buildargs" for an overview of how build arguments work.
+
+  Most operations take a build directory. The build arguments are taken from
+  the previous build done in that directory. If a command specifies --args, it
+  will override the previous arguments stored in the build directory, and use
+  the specified ones.
+
+  The args specified will be saved to the build directory for subsequent
+  commands. Specifying --args="" will clear all build arguments.
+
+Formatting
+
+  The value of the switch is interpreted in GN syntax. For typical usage of
+  string arguments, you will need to be careful about escaping of quotes.
+
+Examples
+
+  gn gen out/Default --args="foo=\"bar\""
+
+  gn gen out/Default --args='foo="bar" enable=true blah=7'
+
+  gn check out/Default --args=""
+    Clears existing build args from the directory.
+
+  gn desc out/Default --args="some_list=[1, false, \"foo\"]"
+)";
 
 #define COLOR_HELP_LONG \
     "--[no]color: Forces colored output on or off.\n"\
@@ -60,37 +60,39 @@
 const char kDotfile_HelpShort[] =
     "--dotfile: Override the name of the \".gn\" file.";
 const char kDotfile_Help[] =
-    "--dotfile: Override the name of the \".gn\" file.\n"
-    "\n"
-    "  Normally GN loads the \".gn\"file  from the source root for some basic\n"
-    "  configuration (see \"gn help dotfile\"). This flag allows you to\n"
-    "  use a different file.\n"
-    "\n"
-    "  Note that this interacts with \"--root\" in a possibly incorrect way.\n"
-    "  It would be nice to test the edge cases and document or fix.\n";
+    R"(--dotfile: Override the name of the ".gn" file.
+
+  Normally GN loads the ".gn"file  from the source root for some basic
+  configuration (see "gn help dotfile"). This flag allows you to
+  use a different file.
+
+  Note that this interacts with "--root" in a possibly incorrect way.
+  It would be nice to test the edge cases and document or fix.
+)";
 
 const char kFailOnUnusedArgs[] = "fail-on-unused-args";
 const char kFailOnUnusedArgs_HelpShort[] =
     "--fail-on-unused-args: Treat unused build args as fatal errors.";
 const char kFailOnUnusedArgs_Help[] =
-    "--fail-on-unused-args: Treat unused build args as fatal errors.\n"
-    "\n"
-    "  If you set a value in a build's \"gn args\" and never use it in the\n"
-    "  build (in a declare_args() block), GN will normally print an error\n"
-    "  but not fail the build.\n"
-    "\n"
-    "  In many cases engineers would use build args to enable or disable\n"
-    "  features that would sometimes get removed. It would by annoying to\n"
-    "  block work for typically benign problems. In Chrome in particular,\n"
-    "  flags might be configured for build bots in a separate infrastructure\n"
-    "  repository, or a declare_args block might be changed in a third party\n"
-    "  repository. Treating these errors as blocking forced complex multi-\n"
-    "  way patches to land what would otherwise be simple changes.\n"
-    "\n"
-    "  In some cases, such concerns are not as important, and a mismatch\n"
-    "  in build flags between the invoker of the build and the build files\n"
-    "  represents a critical mismatch that should be immediately fixed. Such\n"
-    "  users can set this flag to force GN to fail in that case.\n";
+    R"(--fail-on-unused-args: Treat unused build args as fatal errors.
+
+  If you set a value in a build's "gn args" and never use it in the build (in
+  a declare_args() block), GN will normally print an error but not fail the
+  build.
+
+  In many cases engineers would use build args to enable or disable features
+  that would sometimes get removed. It would by annoying to block work for
+  typically benign problems. In Chrome in particular, flags might be configured
+  for build bots in a separate infrastructure repository, or a declare_args
+  block might be changed in a third party repository. Treating these errors as
+  blocking forced complex multi- way patches to land what would otherwise be
+  simple changes.
+
+  In some cases, such concerns are not as important, and a mismatch in build
+  flags between the invoker of the build and the build files represents a
+  critical mismatch that should be immediately fixed. Such users can set this
+  flag to force GN to fail in that case.
+)";
 
 const char kMarkdown[] = "markdown";
 const char kMarkdown_HelpShort[] =
@@ -107,127 +109,135 @@
 const char kScriptExecutable_HelpShort[] =
     "--script-executable: Set the executable used to execute scripts.";
 const char kScriptExecutable_Help[] =
-    "--script-executable: Set the executable used to execute scripts.\n"
-    "\n"
-    "  By default GN searches the PATH for Python to execute scripts in\n"
-    "  action targets and exec_script calls. This flag allows the\n"
-    "  specification of a specific Python executable or potentially\n"
-    "  a different language interpreter.\n";
+    R"(--script-executable: Set the executable used to execute scripts.
+
+  By default GN searches the PATH for Python to execute scripts in action
+  targets and exec_script calls. This flag allows the specification of a
+  specific Python executable or potentially a different language
+  interpreter.
+)";
 
 const char kQuiet[] = "q";
 const char kQuiet_HelpShort[] =
     "-q: Quiet mode. Don't print output on success.";
 const char kQuiet_Help[] =
-    "-q: Quiet mode. Don't print output on success.\n"
-    "\n"
-    "  This is useful when running as a part of another script.\n";
+    R"(-q: Quiet mode. Don't print output on success.
+
+  This is useful when running as a part of another script.
+)";
 
 const char kRoot[] = "root";
 const char kRoot_HelpShort[] =
     "--root: Explicitly specify source root.";
 const char kRoot_Help[] =
-    "--root: Explicitly specify source root.\n"
-    "\n"
-    "  Normally GN will look up in the directory tree from the current\n"
-    "  directory to find a \".gn\" file. The source root directory specifies\n"
-    "  the meaning of \"//\" beginning with paths, and the BUILD.gn file\n"
-    "  in that directory will be the first thing loaded.\n"
-    "\n"
-    "  Specifying --root allows GN to do builds in a specific directory\n"
-    "  regardless of the current directory.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gn gen //out/Default --root=/home/baracko/src\n"
-    "\n"
-    "  gn desc //out/Default --root=\"C:\\Users\\BObama\\My Documents\\foo\"\n";
+    R"(--root: Explicitly specify source root.
+
+  Normally GN will look up in the directory tree from the current directory to
+  find a ".gn" file. The source root directory specifies the meaning of "//"
+  beginning with paths, and the BUILD.gn file in that directory will be the
+  first thing loaded.
+
+  Specifying --root allows GN to do builds in a specific directory regardless
+  of the current directory.
+
+Examples
+
+  gn gen //out/Default --root=/home/baracko/src
+
+  gn desc //out/Default --root="C:\Users\BObama\My Documents\foo"
+)";
 
 const char kRuntimeDepsListFile[] = "runtime-deps-list-file";
 const char kRuntimeDepsListFile_HelpShort[] =
     "--runtime-deps-list-file: Save runtime dependencies for targets in file.";
 const char kRuntimeDepsListFile_Help[] =
-    "--runtime-deps-list-file: Save runtime dependencies for targets in file.\n"
-    "\n"
-    "  --runtime-deps-list-file=<filename>\n"
-    "\n"
-    "  Where <filename> is a text file consisting of the labels, one per\n"
-    "  line, of the targets for which runtime dependencies are desired.\n"
-    "\n"
-    "  See \"gn help runtime_deps\" for a description of how runtime\n"
-    "  dependencies are computed.\n"
-    "\n"
-    "Runtime deps output file\n"
-    "\n"
-    "  For each target requested, GN will write a separate runtime dependency\n"
-    "  file. The runtime dependency file will be in the output directory\n"
-    "  alongside the output file of the target, with a \".runtime_deps\"\n"
-    "  extension. For example, if the target \"//foo:bar\" is listed in the\n"
-    "  input file, and that target produces an output file \"bar.so\", GN\n"
-    "  will create a file \"bar.so.runtime_deps\" in the build directory.\n"
-    "\n"
-    "  If a source set, action, copy, or group is listed, the runtime deps\n"
-    "  file will correspond to the .stamp file corresponding to that target.\n"
-    "  This is probably not useful; the use-case for this feature is\n"
-    "  generally executable targets.\n"
-    "\n"
-    "  The runtime dependency file will list one file per line, with no\n"
-    "  escaping. The files will be relative to the root_build_dir. The first\n"
-    "  line of the file will be the main output file of the target itself\n"
-    "  (in the above example, \"bar.so\").\n";
+    R"(--runtime-deps-list-file: Save runtime dependencies for targets in file.
+
+  --runtime-deps-list-file=<filename>
+
+  Where <filename> is a text file consisting of the labels, one per line, of
+  the targets for which runtime dependencies are desired.
+
+  See "gn help runtime_deps" for a description of how runtime dependencies are
+  computed.
+
+Runtime deps output file
+
+  For each target requested, GN will write a separate runtime dependency file.
+  The runtime dependency file will be in the output directory alongside the
+  output file of the target, with a ".runtime_deps" extension. For example, if
+  the target "//foo:bar" is listed in the input file, and that target produces
+  an output file "bar.so", GN will create a file "bar.so.runtime_deps" in the
+  build directory.
+
+  If a source set, action, copy, or group is listed, the runtime deps file will
+  correspond to the .stamp file corresponding to that target. This is probably
+  not useful; the use-case for this feature is generally executable targets.
+
+  The runtime dependency 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 (in the above example,
+  "bar.so").
+)";
 
 const char kThreads[] = "threads";
 const char kThreads_HelpShort[] =
     "--threads: Specify number of worker threads.";
 const char kThreads_Help[] =
-    "--threads: Specify number of worker threads.\n"
-    "\n"
-    "  GN runs many threads to load and run build files. This can make\n"
-    "  debugging challenging. Or you may want to experiment with different\n"
-    "  values to see how it affects performance.\n"
-    "\n"
-    "  The parameter is the number of worker threads. This does not count the\n"
-    "  main thread (so there are always at least two).\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gen gen out/Default --threads=1\n";
+    R"(--threads: Specify number of worker threads.
+
+  GN runs many threads to load and run build files. This can make debugging
+  challenging. Or you may want to experiment with different values to see how
+  it affects performance.
+
+  The parameter is the number of worker threads. This does not count the main
+  thread (so there are always at least two).
+
+Examples
+
+  gen gen out/Default --threads=1
+)";
 
 const char kTime[] = "time";
 const char kTime_HelpShort[] =
     "--time: Outputs a summary of how long everything took.";
 const char kTime_Help[] =
-    "--time: Outputs a summary of how long everything took.\n"
-    "\n"
-    "  Hopefully self-explanatory.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gn gen out/Default --time\n";
+    R"(--time: Outputs a summary of how long everything took.
+
+  Hopefully self-explanatory.
+
+Examples
+
+  gn gen out/Default --time
+)";
 
 const char kTracelog[] = "tracelog";
 const char kTracelog_HelpShort[] =
     "--tracelog: Writes a Chrome-compatible trace log to the given file.";
 const char kTracelog_Help[] =
-    "--tracelog: Writes a Chrome-compatible trace log to the given file.\n"
-    "\n"
-    "  The trace log will show file loads, executions, scripts, and writes.\n"
-    "  This allows performance analysis of the generation step.\n"
-    "\n"
-    "  To view the trace, open Chrome and navigate to \"chrome://tracing/\",\n"
-    "  then press \"Load\" and specify the file you passed to this parameter.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gn gen out/Default --tracelog=mytrace.trace\n";
+    R"(--tracelog: Writes a Chrome-compatible trace log to the given file.
+
+  The trace log will show file loads, executions, scripts, and writes. This
+  allows performance analysis of the generation step.
+
+  To view the trace, open Chrome and navigate to "chrome://tracing/", then
+  press "Load" and specify the file you passed to this parameter.
+
+Examples
+
+  gn gen out/Default --tracelog=mytrace.trace
+)";
 
 const char kVerbose[] = "v";
 const char kVerbose_HelpShort[] =
     "-v: Verbose logging.";
 const char kVerbose_Help[] =
-    "-v: Verbose logging.\n"
-    "\n"
-    "  This will spew logging events to the console for debugging issues.\n"
-    "  Good luck!\n";
+    R"(-v: Verbose logging.
+
+  This will spew logging events to the console for debugging issues.
+
+  Good luck!
+)";
 
 const char kVersion[] = "version";
 const char kVersion_HelpShort[] =
diff --git a/tools/gn/variables.cc b/tools/gn/variables.cc
index 644c835..d387bae 100644
--- a/tools/gn/variables.cc
+++ b/tools/gn/variables.cc
@@ -12,368 +12,374 @@
 const char kHostCpu_HelpShort[] =
     "host_cpu: [string] The processor architecture that GN is running on.";
 const char kHostCpu_Help[] =
-    "host_cpu: The processor architecture that GN is running on.\n"
-    "\n"
-    "  This is value is exposed so that cross-compile toolchains can\n"
-    "  access the host architecture when needed.\n"
-    "\n"
-    "  The value should generally be considered read-only, but it can be\n"
-    "  overriden in order to handle unusual cases where there might\n"
-    "  be multiple plausible values for the host architecture (e.g., if\n"
-    "  you can do either 32-bit or 64-bit builds). The value is not used\n"
-    "  internally by GN for any purpose.\n"
-    "\n"
-    "Some possible values:\n"
-    "  - \"x64\"\n"
-    "  - \"x86\"\n";
+    R"(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"
+)";
 
 const char kHostOs[] = "host_os";
 const char kHostOs_HelpShort[] =
     "host_os: [string] The operating system that GN is running on.";
 const char kHostOs_Help[] =
-    "host_os: [string] The operating system that GN is running on.\n"
-    "\n"
-    "  This value is exposed so that cross-compiles can access the host\n"
-    "  build system's settings.\n"
-    "\n"
-    "  This value should generally be treated as read-only. It, however,\n"
-    "  is not used internally by GN for any purpose.\n"
-    "\n"
-    "Some possible values:\n"
-    "  - \"linux\"\n"
-    "  - \"mac\"\n"
-    "  - \"win\"\n";
+    R"(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"
+)";
 
 const char kInvoker[] = "invoker";
 const char kInvoker_HelpShort[] =
     "invoker: [string] The invoking scope inside a template.";
 const char kInvoker_Help[] =
-    "invoker: [string] The invoking scope inside a template.\n"
-    "\n"
-    "  Inside a template invocation, this variable refers to the scope of\n"
-    "  the invoker of the template. Outside of template invocations, this\n"
-    "  variable is undefined.\n"
-    "\n"
-    "  All of the variables defined inside the template invocation are\n"
-    "  accessible as members of the \"invoker\" scope. This is the way that\n"
-    "  templates read values set by the callers.\n"
-    "\n"
-    "  This is often used with \"defined\" to see if a value is set on the\n"
-    "  invoking scope.\n"
-    "\n"
-    "  See \"gn help template\" for more examples.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  template(\"my_template\") {\n"
-    "    print(invoker.sources)       # Prints [ \"a.cc\", \"b.cc\" ]\n"
-    "    print(defined(invoker.foo))  # Prints false.\n"
-    "    print(defined(invoker.bar))  # Prints true.\n"
-    "  }\n"
-    "\n"
-    "  my_template(\"doom_melon\") {\n"
-    "    sources = [ \"a.cc\", \"b.cc\" ]\n"
-    "    bar = 123\n"
-    "  }\n";
+    R"(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
+  }
+)";
 
 const char kTargetCpu[] = "target_cpu";
 const char kTargetCpu_HelpShort[] =
     "target_cpu: [string] The desired cpu architecture for the build.";
 const char kTargetCpu_Help[] =
-    "target_cpu: The desired cpu architecture for the build.\n"
-    "\n"
-    "  This value should be used to indicate the desired architecture for\n"
-    "  the primary objects of the build. It will match the cpu architecture\n"
-    "  of the default toolchain, but not necessarily the current toolchain.\n"
-    "\n"
-    "  In many cases, this is the same as \"host_cpu\", but in the case\n"
-    "  of cross-compiles, this can be set to something different. This\n"
-    "  value is different from \"current_cpu\" in that it does not change\n"
-    "  based on the current toolchain. When writing rules, \"current_cpu\"\n"
-    "  should be used rather than \"target_cpu\" most of the time.\n"
-    "\n"
-    "  This value is not used internally by GN for any purpose, so it\n"
-    "  may be set to whatever value is needed for the build.\n"
-    "  GN defaults this value to the empty string (\"\") and the\n"
-    "  configuration files should set it to an appropriate value\n"
-    "  (e.g., setting it to the value of \"host_cpu\") if it is not\n"
-    "  overridden on the command line or in the args.gn file.\n"
-    "\n"
-    "  Where practical, use one of the following list of common values:\n"
-    "\n"
-    "Possible values:\n"
-    "  - \"x86\"\n"
-    "  - \"x64\"\n"
-    "  - \"arm\"\n"
-    "  - \"arm64\"\n"
-    "  - \"mipsel\"\n";
+    R"(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"
+)";
 
 const char kTargetName[] = "target_name";
 const char kTargetName_HelpShort[] =
     "target_name: [string] The name of the current target.";
 const char kTargetName_Help[] =
-    "target_name: [string] The name of the current target.\n"
-    "\n"
-    "  Inside a target or template invocation, this variable refers to the\n"
-    "  name given to the target or template invocation. Outside of these,\n"
-    "  this variable is undefined.\n"
-    "\n"
-    "  This is most often used in template definitions to name targets\n"
-    "  defined in the template based on the name of the invocation. This\n"
-    "  is necessary both to ensure generated targets have unique names and\n"
-    "  to generate a target with the exact name of the invocation that\n"
-    "  other targets can depend on.\n"
-    "\n"
-    "  Be aware that this value will always reflect the innermost scope. So\n"
-    "  when defining a target inside a template, target_name will refer to\n"
-    "  the target rather than the template invocation. To get the name of the\n"
-    "  template invocation in this case, you should save target_name to a\n"
-    "  temporary variable outside of any target definitions.\n"
-    "\n"
-    "  See \"gn help template\" for more examples.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  executable(\"doom_melon\") {\n"
-    "    print(target_name)    # Prints \"doom_melon\".\n"
-    "  }\n"
-    "\n"
-    "  template(\"my_template\") {\n"
-    "    print(target_name)    # Prints \"space_ray\" when invoked below.\n"
-    "\n"
-    "    executable(target_name + \"_impl\") {\n"
-    "      print(target_name)  # Prints \"space_ray_impl\".\n"
-    "    }\n"
-    "  }\n"
-    "\n"
-    "  my_template(\"space_ray\") {\n"
-    "  }\n";
+    R"(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") {
+  }
+)";
 
 const char kTargetOs[] = "target_os";
 const char kTargetOs_HelpShort[] =
     "target_os: [string] The desired operating system for the build.";
 const char kTargetOs_Help[] =
-    "target_os: The desired operating system for the build.\n"
-    "\n"
-    "  This value should be used to indicate the desired operating system\n"
-    "  for the primary object(s) of the build. It will match the OS of\n"
-    "  the default toolchain.\n"
-    "\n"
-    "  In many cases, this is the same as \"host_os\", but in the case of\n"
-    "  cross-compiles, it may be different. This variable differs from\n"
-    "  \"current_os\" in that it can be referenced from inside any\n"
-    "  toolchain and will always return the initial value.\n"
-    "\n"
-    "  This should be set to the most specific value possible. So,\n"
-    "  \"android\" or \"chromeos\" should be used instead of \"linux\"\n"
-    "  where applicable, even though Android and ChromeOS are both Linux\n"
-    "  variants. This can mean that one needs to write\n"
-    "\n"
-    "      if (target_os == \"android\" || target_os == \"linux\") {\n"
-    "          # ...\n"
-    "      }\n"
-    "\n"
-    "  and so forth.\n"
-    "\n"
-    "  This value is not used internally by GN for any purpose, so it\n"
-    "  may be set to whatever value is needed for the build.\n"
-    "  GN defaults this value to the empty string (\"\") and the\n"
-    "  configuration files should set it to an appropriate value\n"
-    "  (e.g., setting it to the value of \"host_os\") if it is not\n"
-    "  set via the command line or in the args.gn file.\n"
-    "\n"
-    "  Where practical, use one of the following list of common values:\n"
-    "\n"
-    "Possible values:\n"
-    "  - \"android\"\n"
-    "  - \"chromeos\"\n"
-    "  - \"ios\"\n"
-    "  - \"linux\"\n"
-    "  - \"nacl\"\n"
-    "  - \"mac\"\n"
-    "  - \"win\"\n";
+    R"(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"
+)";
 
 const char kCurrentCpu[] = "current_cpu";
 const char kCurrentCpu_HelpShort[] =
     "current_cpu: [string] The processor architecture of the current "
         "toolchain.";
 const char kCurrentCpu_Help[] =
-    "current_cpu: The processor architecture of the current toolchain.\n"
-    "\n"
-    "  The build configuration usually sets this value based on the value\n"
-    "  of \"host_cpu\" (see \"gn help host_cpu\") and then threads\n"
-    "  this through the toolchain definitions to ensure that it always\n"
-    "  reflects the appropriate value.\n"
-    "\n"
-    "  This value is not used internally by GN for any purpose. It is\n"
-    "  set it to the empty string (\"\") by default but is declared so\n"
-    "  that it can be overridden on the command line if so desired.\n"
-    "\n"
-    "  See \"gn help target_cpu\" for a list of common values returned.\n";
+    R"(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.)";
 
 const char kCurrentOs[] = "current_os";
 const char kCurrentOs_HelpShort[] =
     "current_os: [string] The operating system of the current toolchain.";
 const char kCurrentOs_Help[] =
-    "current_os: The operating system of the current toolchain.\n"
-    "\n"
-    "  The build configuration usually sets this value based on the value\n"
-    "  of \"target_os\" (see \"gn help target_os\"), and then threads this\n"
-    "  through the toolchain definitions to ensure that it always reflects\n"
-    "  the appropriate value.\n"
-    "\n"
-    "  This value is not used internally by GN for any purpose. It is\n"
-    "  set it to the empty string (\"\") by default but is declared so\n"
-    "  that it can be overridden on the command line if so desired.\n"
-    "\n"
-    "  See \"gn help target_os\" for a list of common values returned.\n";
+    R"(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.
+)";
 
 const char kCurrentToolchain[] = "current_toolchain";
 const char kCurrentToolchain_HelpShort[] =
     "current_toolchain: [string] Label of the current toolchain.";
 const char kCurrentToolchain_Help[] =
-    "current_toolchain: Label of the current toolchain.\n"
-    "\n"
-    "  A fully-qualified label representing the current toolchain. You can\n"
-    "  use this to make toolchain-related decisions in the build. See also\n"
-    "  \"default_toolchain\".\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  if (current_toolchain == \"//build:64_bit_toolchain\") {\n"
-    "    executable(\"output_thats_64_bit_only\") {\n"
-    "      ...\n";
+    R"(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") {
+      ...
+)";
 
 const char kDefaultToolchain[] = "default_toolchain";
 const char kDefaultToolchain_HelpShort[] =
     "default_toolchain: [string] Label of the default toolchain.";
 const char kDefaultToolchain_Help[] =
-    "default_toolchain: [string] Label of the default toolchain.\n"
-    "\n"
-    "  A fully-qualified label representing the default toolchain, which may\n"
-    "  not necessarily be the current one (see \"current_toolchain\").\n";
+    R"(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").
+)";
 
 const char kPythonPath[] = "python_path";
 const char kPythonPath_HelpShort[] =
     "python_path: [string] Absolute path of Python.";
 const char kPythonPath_Help[] =
-    "python_path: Absolute path of Python.\n"
-    "\n"
-    "  Normally used in toolchain definitions if running some command\n"
-    "  requires Python. You will normally not need this when invoking scripts\n"
-    "  since GN automatically finds it for you.\n";
+    R"(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.
+)";
 
 const char kRootBuildDir[] = "root_build_dir";
 const char kRootBuildDir_HelpShort[] =
   "root_build_dir: [string] Directory where build commands are run.";
 const char kRootBuildDir_Help[] =
-  "root_build_dir: [string] Directory where build commands are run.\n"
-  "\n"
-  "  This is the root build output directory which will be the current\n"
-  "  directory when executing all compilers and scripts.\n"
-  "\n"
-  "  Most often this is used with rebase_path (see \"gn help rebase_path\")\n"
-  "  to convert arguments to be relative to a script's current directory.\n";
+  R"(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.
+)";
 
 const char kRootGenDir[] = "root_gen_dir";
 const char kRootGenDir_HelpShort[] =
     "root_gen_dir: [string] Directory for the toolchain's generated files.";
 const char kRootGenDir_Help[] =
-    "root_gen_dir: Directory for the toolchain's generated files.\n"
-    "\n"
-    "  Absolute path to the root of the generated output directory tree for\n"
-    "  the current toolchain. An example would be \"//out/Debug/gen\" for the\n"
-    "  default toolchain, or \"//out/Debug/arm/gen\" for the \"arm\"\n"
-    "  toolchain.\n"
-    "\n"
-    "  This is primarily useful for setting up include paths for generated\n"
-    "  files. If you are passing this to a script, you will want to pass it\n"
-    "  through rebase_path() (see \"gn help rebase_path\") to convert it\n"
-    "  to be relative to the build directory.\n"
-    "\n"
-    "  See also \"target_gen_dir\" which is usually a better location for\n"
-    "  generated files. It will be inside the root generated dir.\n";
+    R"(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.
+)";
 
 const char kRootOutDir[] = "root_out_dir";
 const char kRootOutDir_HelpShort[] =
     "root_out_dir: [string] Root directory for toolchain output files.";
 const char kRootOutDir_Help[] =
-    "root_out_dir: [string] Root directory for toolchain output files.\n"
-    "\n"
-    "  Absolute path to the root of the output directory tree for the current\n"
-    "  toolchain. It will not have a trailing slash.\n"
-    "\n"
-    "  For the default toolchain this will be the same as the root_build_dir.\n"
-    "  An example would be \"//out/Debug\" for the default toolchain, or\n"
-    "  \"//out/Debug/arm\" for the \"arm\" toolchain.\n"
-    "\n"
-    "  This is primarily useful for setting up script calls. If you are\n"
-    "  passing this to a script, you will want to pass it through\n"
-    "  rebase_path() (see \"gn help rebase_path\") to convert it\n"
-    "  to be relative to the build directory.\n"
-    "\n"
-    "  See also \"target_out_dir\" which is usually a better location for\n"
-    "  output files. It will be inside the root output dir.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  action(\"myscript\") {\n"
-    "    # Pass the output dir to the script.\n"
-    "    args = [ \"-o\", rebase_path(root_out_dir, root_build_dir) ]\n"
-    "  }\n";
+    R"(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) ]
+  }
+)";
 
 const char kTargetGenDir[] = "target_gen_dir";
 const char kTargetGenDir_HelpShort[] =
     "target_gen_dir: [string] Directory for a target's generated files.";
 const char kTargetGenDir_Help[] =
-    "target_gen_dir: Directory for a target's generated files.\n"
-    "\n"
-    "  Absolute path to the target's generated file directory. This will be\n"
-    "  the \"root_gen_dir\" followed by the relative path to the current\n"
-    "  build file. If your file is in \"//tools/doom_melon\" then\n"
-    "  target_gen_dir would be \"//out/Debug/gen/tools/doom_melon\". It will\n"
-    "  not have a trailing slash.\n"
-    "\n"
-    "  This is primarily useful for setting up include paths for generated\n"
-    "  files. If you are passing this to a script, you will want to pass it\n"
-    "  through rebase_path() (see \"gn help rebase_path\") to convert it\n"
-    "  to be relative to the build directory.\n"
-    "\n"
-    "  See also \"gn help root_gen_dir\".\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  action(\"myscript\") {\n"
-    "    # Pass the generated output dir to the script.\n"
-    "    args = [ \"-o\", rebase_path(target_gen_dir, root_build_dir) ]"
-    "\n"
-    "  }\n";
+    R"(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) ]"
+  }
+)";
 
 const char kTargetOutDir[] = "target_out_dir";
 const char kTargetOutDir_HelpShort[] =
     "target_out_dir: [string] Directory for target output files.";
 const char kTargetOutDir_Help[] =
-    "target_out_dir: [string] Directory for target output files.\n"
-    "\n"
-    "  Absolute path to the target's generated file directory. If your\n"
-    "  current target is in \"//tools/doom_melon\" then this value might be\n"
-    "  \"//out/Debug/obj/tools/doom_melon\". It will not have a trailing\n"
-    "  slash.\n"
-    "\n"
-    "  This is primarily useful for setting up arguments for calling\n"
-    "  scripts. If you are passing this to a script, you will want to pass it\n"
-    "  through rebase_path() (see \"gn help rebase_path\") to convert it\n"
-    "  to be relative to the build directory.\n"
-    "\n"
-    "  See also \"gn help root_out_dir\".\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  action(\"myscript\") {\n"
-    "    # Pass the output dir to the script.\n"
-    "    args = [ \"-o\", rebase_path(target_out_dir, root_build_dir) ]"
-    "\n"
-    "  }\n";
+    R"(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) ]"
+
+  }
+)";
 
 // Target variables ------------------------------------------------------------
 
@@ -399,296 +405,300 @@
 const char kAllDependentConfigs_HelpShort[] =
     "all_dependent_configs: [label list] Configs to be forced on dependents.";
 const char kAllDependentConfigs_Help[] =
-    "all_dependent_configs: Configs to be forced on dependents.\n"
-    "\n"
-    "  A list of config labels.\n"
-    "\n"
-    "  All targets depending on this one, and recursively, all targets\n"
-    "  depending on those, will have the configs listed in this variable\n"
-    "  added to them. These configs will also apply to the current target.\n"
-    "\n"
-    "  This addition happens in a second phase once a target and all of its\n"
-    "  dependencies have been resolved. Therefore, a target will not see\n"
-    "  these force-added configs in their \"configs\" variable while the\n"
-    "  script is running, and then can not be removed. As a result, this\n"
-    "  capability should generally only be used to add defines and include\n"
-    "  directories necessary to compile a target's headers.\n"
-    "\n"
-    "  See also \"public_configs\".\n"
+    R"(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 then 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".
+)"
     COMMON_ORDERING_HELP;
 
 const char kAllowCircularIncludesFrom[] = "allow_circular_includes_from";
 const char kAllowCircularIncludesFrom_HelpShort[] =
     "allow_circular_includes_from: [label list] Permit includes from deps.";
 const char kAllowCircularIncludesFrom_Help[] =
-    "allow_circular_includes_from: Permit includes from deps.\n"
-    "\n"
-    "  A list of target labels. Must be a subset of the target's \"deps\".\n"
-    "  These targets will be permitted to include headers from the current\n"
-    "  target despite the dependency going in the opposite direction.\n"
-    "\n"
-    "  When you use this, both targets must be included in a final binary\n"
-    "  for it to link. To keep linker errors from happening, it is good\n"
-    "  practice to have all external dependencies depend only on one of\n"
-    "  the two targets, and to set the visibility on the other to enforce\n"
-    "  this. Thus the targets will always be linked together in any output.\n"
-    "\n"
-    "Details\n"
-    "\n"
-    "  Normally, for a file in target A to include a file from target B,\n"
-    "  A must list B as a dependency. This invariant is enforced by the\n"
-    "  \"gn check\" command (and the --check flag to \"gn gen\" -- see\n"
-    "  \"gn help check\").\n"
-    "\n"
-    "  Sometimes, two targets might be the same unit for linking purposes\n"
-    "  (two source sets or static libraries that would always be linked\n"
-    "  together in a final executable or shared library) and they each\n"
-    "  include headers from the other: you want A to be able to include B's\n"
-    "  headers, and B to include A's headers. This is not an ideal situation\n"
-    "  but is sometimes unavoidable.\n"
-    "\n"
-    "  This list, if specified, lists which of the dependencies of the\n"
-    "  current target can include header files from the current target.\n"
-    "  That is, if A depends on B, B can only include headers from A if it is\n"
-    "  in A's allow_circular_includes_from list. Normally includes must\n"
-    "  follow the direction of dependencies, this flag allows them to go\n"
-    "  in the opposite direction.\n"
-    "\n"
-    "Danger\n"
-    "\n"
-    "  In the above example, A's headers are likely to include headers from\n"
-    "  A's dependencies. Those dependencies may have public_configs that\n"
-    "  apply flags, defines, and include paths that make those headers work\n"
-    "  properly.\n"
-    "\n"
-    "  With allow_circular_includes_from, B can include A's headers, and\n"
-    "  transitively from A's dependencies, without having the dependencies\n"
-    "  that would bring in the public_configs those headers need. The result\n"
-    "  may be errors or inconsistent builds.\n"
-    "\n"
-    "  So when you use allow_circular_includes_from, make sure that any\n"
-    "  compiler settings, flags, and include directories are the same between\n"
-    "  both targets (consider putting such things in a shared config they can\n"
-    "  both reference). Make sure the dependencies are also the same (you\n"
-    "  might consider a group to collect such dependencies they both\n"
-    "  depend on).\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  source_set(\"a\") {\n"
-    "    deps = [ \":b\", \":a_b_shared_deps\" ]\n"
-    "    allow_circular_includes_from = [ \":b\" ]\n"
-    "    ...\n"
-    "  }\n"
-    "\n"
-    "  source_set(\"b\") {\n"
-    "    deps = [ \":a_b_shared_deps\" ]\n"
-    "    # Sources here can include headers from a despite lack of deps.\n"
-    "    ...\n"
-    "  }\n"
-    "\n"
-    "  group(\"a_b_shared_deps\") {\n"
-    "    public_deps = [ \":c\" ]\n"
-    "  }\n";
+    R"(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" ]
+  }
+)";
 
 const char kArflags[] = "arflags";
 const char kArflags_HelpShort[] =
     "arflags: [string list] Arguments passed to static_library archiver.";
 const char kArflags_Help[] =
-    "arflags: Arguments passed to static_library archiver.\n"
-    "\n"
-    "  A list of flags passed to the archive/lib command that creates static\n"
-    "  libraries.\n"
-    "\n"
-    "  arflags are NOT pushed to dependents, so applying arflags to source\n"
-    "  sets or any other target type will be a no-op. As with ldflags,\n"
-    "  you could put the arflags in a config and set that as a public or\n"
-    "  \"all dependent\" config, but that will likely not be what you want.\n"
-    "  If you have a chain of static libraries dependent on each other,\n"
-    "  this can cause the flags to propagate up to other static libraries.\n"
-    "  Due to the nature of how arflags are typically used, you will normally\n"
-    "  want to apply them directly on static_library targets themselves.\n"
+    R"(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.
+)"
     COMMON_ORDERING_HELP;
 
 const char kArgs[] = "args";
 const char kArgs_HelpShort[] =
     "args: [string list] Arguments passed to an action.";
 const char kArgs_Help[] =
-    "args: Arguments passed to an action.\n"
-    "\n"
-    "  For action and action_foreach targets, args is the list of arguments\n"
-    "  to pass to the script. Typically you would use source expansion (see\n"
-    "  \"gn help source_expansion\") to insert the source file names.\n"
-    "\n"
-    "  See also \"gn help action\" and \"gn help action_foreach\".\n";
+    R"(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".
+)";
 
 const char kAssertNoDeps[] = "assert_no_deps";
 const char kAssertNoDeps_HelpShort[] =
     "assert_no_deps: [label pattern list] Ensure no deps on these targets.";
 const char kAssertNoDeps_Help[] =
-    "assert_no_deps: Ensure no deps on these targets.\n"
-    "\n"
-    "  A list of label patterns.\n"
-    "\n"
-    "  This list is a list of patterns that must not match any of the\n"
-    "  transitive dependencies of the target. These include all public,\n"
-    "  private, and data dependencies, and cross shared library boundaries.\n"
-    "  This allows you to express that undesirable code isn't accidentally\n"
-    "  added to downstream dependencies in a way that might otherwise be\n"
-    "  difficult to notice.\n"
-    "\n"
-    "  Checking does not cross executable boundaries. If a target depends on\n"
-    "  an executable, it's assumed that the executable is a tool that is\n"
-    "  producing part of the build rather than something that is linked and\n"
-    "  distributed. This allows assert_no_deps to express what is distributed\n"
-    "  in the final target rather than depend on the internal build steps\n"
-    "  (which may include non-distributable code).\n"
-    "\n"
-    "  See \"gn help label_pattern\" for the format of the entries in the\n"
-    "  list. These patterns allow blacklisting individual targets or whole\n"
-    "  directory hierarchies.\n"
-    "\n"
-    "  Sometimes it is desirable to enforce that many targets have no\n"
-    "  dependencies on a target or set of targets. One efficient way to\n"
-    "  express this is to create a group with the assert_no_deps rule on\n"
-    "  it, and make that group depend on all targets you want to apply that\n"
-    "  assertion to.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  executable(\"doom_melon\") {\n"
-    "    deps = [ \"//foo:bar\" ]\n"
-    "    ...\n"
-    "    assert_no_deps = [\n"
-    "      \"//evil/*\",  # Don't link any code from the evil directory.\n"
-    "      \"//foo:test_support\",  # This target is also disallowed.\n"
-    "    ]\n"
-    "  }\n";
+    R"(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.
+    ]
+  }
+)";
 
 const char kBundleRootDir[] = "bundle_root_dir";
 const char kBundleRootDir_HelpShort[] =
     "bundle_root_dir: Expansion of {{bundle_root_dir}} in create_bundle.";
 const char kBundleRootDir_Help[] =
-    "bundle_root_dir: Expansion of {{bundle_root_dir}} in create_bundle.\n"
-    "\n"
-    "  A string corresponding to a path in root_build_dir.\n"
-    "\n"
-    "  This string is used by the \"create_bundle\" target to expand the\n"
-    "  {{bundle_root_dir}} of the \"bundle_data\" target it depends on.\n"
-    "  This must correspond to a path under root_build_dir.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  bundle_data(\"info_plist\") {\n"
-    "    sources = [ \"Info.plist\" ]\n"
-    "    outputs = [ \"{{bundle_root_dir}}/Info.plist\" ]\n"
-    "  }\n"
-    "\n"
-    "  create_bundle(\"doom_melon.app\") {\n"
-    "    deps = [ \":info_plist\" ]\n"
-    "    bundle_root_dir = root_build_dir + \"/doom_melon.app/Contents\"\n"
-    "    bundle_resources_dir = bundle_root_dir + \"/Resources\"\n"
-    "    bundle_executable_dir = bundle_root_dir + \"/MacOS\"\n"
-    "    bundle_plugins_dir = bundle_root_dir + \"/PlugIns\"\n"
-    "  }\n";
+    R"(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_root_dir}}/Info.plist" ]
+  }
+
+  create_bundle("doom_melon.app") {
+    deps = [ ":info_plist" ]
+    bundle_root_dir = root_build_dir + "/doom_melon.app/Contents"
+    bundle_resources_dir = bundle_root_dir + "/Resources"
+    bundle_executable_dir = bundle_root_dir + "/MacOS"
+    bundle_plugins_dir = bundle_root_dir + "/PlugIns"
+  }
+)";
 
 const char kBundleResourcesDir[] = "bundle_resources_dir";
 const char kBundleResourcesDir_HelpShort[] =
     "bundle_resources_dir: "
         "Expansion of {{bundle_resources_dir}} in create_bundle.";
 const char kBundleResourcesDir_Help[] =
-    "bundle_resources_dir: "
-        "Expansion of {{bundle_resources_dir}} in create_bundle.\n"
-    "\n"
-    "  A string corresponding to a path in $root_build_dir.\n"
-    "\n"
-    "  This string is used by the \"create_bundle\" target to expand the\n"
-    "  {{bundle_resources_dir}} of the \"bundle_data\" target it depends on.\n"
-    "  This must correspond to a path under \"bundle_root_dir\".\n"
-    "\n"
-    "  See \"gn help bundle_root_dir\" for examples.\n";
+    R"(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.
+)";
 
 const char kBundleDepsFilter[] = "bundle_deps_filter";
 const char kBundleDepsFilter_HelpShort[] =
     "bundle_deps_filter: [label list] A list of labels that are filtered out.";
 const char kBundleDepsFilter_Help[] =
-    "bundle_deps_filter: [label list] A list of labels that are filtered out.\n"
-    "\n"
-    "  A list of target labels.\n"
-    "\n"
-    "  This list contains target label patterns that should be filtered out\n"
-    "  when creating the bundle. Any target matching one of those label will\n"
-    "  be removed from the dependencies of the create_bundle target.\n"
-    "\n"
-    "  This is mostly useful when creating application extension bundle as\n"
-    "  the application extension has access to runtime resources from the\n"
-    "  application bundle and thus do not require a second copy.\n"
-    "\n"
-    "  See \"gn help create_bundle\" for more information.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  create_bundle(\"today_extension\") {\n"
-    "    deps = [\n"
-    "      \"//base\"\n"
-    "    ]\n"
-    "    bundle_root_dir = \"$root_out_dir/today_extension.appex\"\n"
-    "    bundle_deps_filter = [\n"
-    "      # The extension uses //base but does not use any function calling\n"
-    "      # into third_party/icu and thus does not need the icudtl.dat file.\n"
-    "      \"//third_party/icu:icudata\",\n"
-    "    ]\n"
-    "  }\n";
+    R"(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",
+    ]
+  }
+)";
 
 const char kBundleExecutableDir[] = "bundle_executable_dir";
 const char kBundleExecutableDir_HelpShort[] =
     "bundle_executable_dir: "
         "Expansion of {{bundle_executable_dir}} in create_bundle";
 const char kBundleExecutableDir_Help[] =
-    "bundle_executable_dir: "
-        "Expansion of {{bundle_executable_dir}} in create_bundle.\n"
-    "\n"
-    "  A string corresponding to a path in $root_build_dir.\n"
-    "\n"
-    "  This string is used by the \"create_bundle\" target to expand the\n"
-    "  {{bundle_executable_dir}} of the \"bundle_data\" target it depends on.\n"
-    "  This must correspond to a path under \"bundle_root_dir\".\n"
-    "\n"
-    "  See \"gn help bundle_root_dir\" for examples.\n";
+    R"(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.
+)";
 
 const char kBundlePlugInsDir[] = "bundle_plugins_dir";
 const char kBundlePlugInsDir_HelpShort[] =
     "bundle_plugins_dir: "
         "Expansion of {{bundle_plugins_dir}} in create_bundle.";
 const char kBundlePlugInsDir_Help[] =
-    "bundle_plugins_dir: "
-        "Expansion of {{bundle_plugins_dir}} in create_bundle.\n"
-    "\n"
-    "  A string corresponding to a path in $root_build_dir.\n"
-    "\n"
-    "  This string is used by the \"create_bundle\" target to expand the\n"
-    "  {{bundle_plugins_dir}} of the \"bundle_data\" target it depends on.\n"
-    "  This must correspond to a path under \"bundle_root_dir\".\n"
-    "\n"
-    "  See \"gn help bundle_root_dir\" for examples.\n";
+    R"(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.
+)";
 
 const char kCflags[] = "cflags";
 const char kCflags_HelpShort[] =
     "cflags: [string list] Flags passed to all C compiler variants.";
 const char kCommonCflagsHelp[] =
-    "cflags*: Flags passed to the C compiler.\n"
-    "\n"
-    "  A list of strings.\n"
-    "\n"
-    "  \"cflags\" are passed to all invocations of the C, C++, Objective C,\n"
-    "  and Objective C++ compilers.\n"
-    "\n"
-    "  To target one of these variants individually, use \"cflags_c\",\n"
-    "  \"cflags_cc\", \"cflags_objc\", and \"cflags_objcc\",\n"
-    "  respectively. These variant-specific versions of cflags* will be\n"
-    "  appended on the compiler command line after \"cflags\".\n"
-    "\n"
-    "  See also \"asmflags\" for flags for assembly-language files.\n"
+    R"(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.
+)"
     COMMON_ORDERING_HELP;
 const char* kCflags_Help = kCommonCflagsHelp;
 
@@ -696,12 +706,13 @@
 const char kAsmflags_HelpShort[] =
     "asmflags: [string list] Flags passed to the assembler.";
 const char* kAsmflags_Help =
-    "asmflags: Flags passed to the assembler.\n"
-    "\n"
-    "  A list of strings.\n"
-    "\n"
-    "  \"asmflags\" are passed to any invocation of a tool that takes an\n"
-    "  .asm or .S file as input.\n"
+    R"(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.
+)"
     COMMON_ORDERING_HELP;
 
 const char kCflagsC[] = "cflags_c";
@@ -728,470 +739,473 @@
 const char kCheckIncludes_HelpShort[] =
     "check_includes: [boolean] Controls whether a target's files are checked.";
 const char kCheckIncludes_Help[] =
-    "check_includes: [boolean] Controls whether a target's files are checked.\n"
-    "\n"
-    "  When true (the default), the \"gn check\" command (as well as\n"
-    "  \"gn gen\" with the --check flag) will check this target's sources\n"
-    "  and headers for proper dependencies.\n"
-    "\n"
-    "  When false, the files in this target will be skipped by default.\n"
-    "  This does not affect other targets that depend on the current target,\n"
-    "  it just skips checking the includes of the current target's files.\n"
-    "\n"
-    "  If there are a few conditionally included headers that trip up\n"
-    "  checking, you can exclude headers individually by annotating them with\n"
-    "  \"nogncheck\" (see \"gn help nogncheck\").\n"
-    "\n"
-    "  The topic \"gn help check\" has general information on how checking\n"
-    "  works and advice on how to pass a check in problematic cases.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  source_set(\"busted_includes\") {\n"
-    "    # This target's includes are messed up, exclude it from checking.\n"
-    "    check_includes = false\n"
-    "    ...\n"
-    "  }\n";
+    R"(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
+    ...
+  }
+)";
 
 const char kCodeSigningArgs[] = "code_signing_args";
 const char kCodeSigningArgs_HelpShort[] =
     "code_signing_args: [string list] Arguments passed to code signing script.";
 const char kCodeSigningArgs_Help[] =
-    "code_signing_args: [string list] Arguments passed to code signing "
-        "script.\n"
-    "\n"
-    "  For create_bundle targets, code_signing_args is the list of arguments\n"
-    "  to pass to the code signing script. Typically you would use source\n"
-    "  expansion (see \"gn help source_expansion\") to insert the source file\n"
-    "  names.\n"
-    "\n"
-    "  See also \"gn help create_bundle\".\n";
+    R"(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".
+)";
 
 const char kCodeSigningScript[] = "code_signing_script";
 const char kCodeSigningScript_HelpShort[] =
     "code_signing_script: [file name] Script for code signing.";
 const char kCodeSigningScript_Help[] =
-    "code_signing_script: [file name] Script for code signing."
-    "\n"
-    "  An absolute or buildfile-relative file name of a Python script to run\n"
-    "  for a create_bundle target to perform code signing step.\n"
-    "\n"
-    "  See also \"gn help create_bundle\".\n";
+    R"(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".
+)";
 
 const char kCodeSigningSources[] = "code_signing_sources";
 const char kCodeSigningSources_HelpShort[] =
     "code_signing_sources: [file list] Sources for code signing step.";
 const char kCodeSigningSources_Help[] =
-    "code_signing_sources: [file list] Sources for code signing step.\n"
-    "\n"
-    "  A list of files used as input for code signing script step of a\n"
-    "  create_bundle target. Non-absolute paths will be resolved relative to\n"
-    "  the current build file.\n"
-    "\n"
-    "  See also \"gn help create_bundle\".\n";
+    R"(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".
+)";
 
 const char kCodeSigningOutputs[] = "code_signing_outputs";
 const char kCodeSigningOutputs_HelpShort[] =
     "code_signing_outputs: [file list] Output files for code signing step.";
 const char kCodeSigningOutputs_Help[] =
-    "code_signing_outputs: [file list] Output files for code signing step.\n"
-    "\n"
-    "  Outputs from the code signing step of a create_bundle target. Must\n"
-    "  refer to files in the build directory.\n"
-    "\n"
-    "  See also \"gn help create_bundle\".\n";
+    R"(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".
+)";
 
 const char kCompleteStaticLib[] = "complete_static_lib";
 const char kCompleteStaticLib_HelpShort[] =
     "complete_static_lib: [boolean] Links all deps into a static library.";
 const char kCompleteStaticLib_Help[] =
-    "complete_static_lib: [boolean] Links all deps into a static library.\n"
-    "\n"
-    "  A static library normally doesn't include code from dependencies, but\n"
-    "  instead forwards the static libraries and source sets in its deps up\n"
-    "  the dependency chain until a linkable target (an executable or shared\n"
-    "  library) is reached. The final linkable target only links each static\n"
-    "  library once, even if it appears more than once in its dependency\n"
-    "  graph.\n"
-    "\n"
-    "  In some cases the static library might be the final desired output.\n"
-    "  For example, you may be producing a static library for distribution to\n"
-    "  third parties. In this case, the static library should include code\n"
-    "  for all dependencies in one complete package. However, complete static\n"
-    "  libraries themselves are never linked into other complete static\n"
-    "  libraries. All complete static libraries are for distribution and\n"
-    "  linking them in would cause code duplication in this case. If the\n"
-    "  static library is not for distribution, it should not be complete.\n"
-    "\n"
-    "  GN treats non-complete static libraries as source sets when they are\n"
-    "  linked into complete static libraries. This is done because some tools\n"
-    "  like AR do not handle dependent static libraries properly. This makes\n"
-    "  it easier to write \"alink\" rules.\n"
-    "\n"
-    "  In rare cases it makes sense to list a header in more than one\n"
-    "  target if it could be considered conceptually a member of both.\n"
-    "  libraries.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  static_library(\"foo\") {\n"
-    "    complete_static_lib = true\n"
-    "    deps = [ \"bar\" ]\n"
-    "  }\n";
+    R"(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" ]
+  }
+)";
 
 const char kConfigs[] = "configs";
 const char kConfigs_HelpShort[] =
     "configs: [label list] Configs applying to this target or config.";
 const char kConfigs_Help[] =
-    "configs: Configs applying to this target or config.\n"
-    "\n"
-    "  A list of config labels.\n"
-    "\n"
-    "Configs on a target\n"
-    "\n"
-    "  When used on a target, the include_dirs, defines, etc. in each config\n"
-    "  are appended in the order they appear to the compile command for each\n"
-    "  file in the target. They will appear after the include_dirs, defines,\n"
-    "  etc. that the target sets directly.\n"
-    "\n"
-    "  Since configs apply after the values set on a target, directly setting\n"
-    "  a compiler flag will prepend it to the command line. If you want to\n"
-    "  append a flag instead, you can put that flag in a one-off config and\n"
-    "  append that config to the target's configs list.\n"
-    "\n"
-    "  The build configuration script will generally set up the default\n"
-    "  configs applying to a given target type (see \"set_defaults\").\n"
-    "  When a target is being defined, it can add to or remove from this\n"
-    "  list.\n"
-    "\n"
-    "Configs on a config\n"
-    "\n"
-    "  It is possible to create composite configs by specifying configs on a\n"
-    "  config. One might do this to forward values, or to factor out blocks\n"
-    "  of settings from very large configs into more manageable named chunks.\n"
-    "\n"
-    "  In this case, the composite config is expanded to be the concatenation\n"
-    "  of its own values, and in order, the values from its sub-configs\n"
-    "  *before* anything else happens. This has some ramifications:\n"
-    "\n"
-    "   - A target has no visibility into a config's sub-configs. Target\n"
-    "     code only sees the name of the composite config. It can't remove\n"
-    "     sub-configs or opt in to only parts of it. The composite config may\n"
-    "     not even be defined before the target is.\n"
-    "\n"
-    "   - You can get duplication of values if a config is listed twice, say,\n"
-    "     on a target and in a sub-config that also applies. In other cases,\n"
-    "     the configs applying to a target are de-duped. It's expected that\n"
-    "     if a config is listed as a sub-config that it is only used in that\n"
-    "     context. (Note that it's possible to fix this and de-dupe, but it's\n"
-    "     not normally relevant and complicates the implementation.)\n"
+    R"(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.)
+)"
     COMMON_ORDERING_HELP
-    "\n"
-    "Example\n"
-    "\n"
-    "  # Configs on a target.\n"
-    "  source_set(\"foo\") {\n"
-    "    # Don't use the default RTTI config that BUILDCONFIG applied to us.\n"
-    "    configs -= [ \"//build:no_rtti\" ]\n"
-    "\n"
-    "    # Add some of our own settings.\n"
-    "    configs += [ \":mysettings\" ]\n"
-    "  }\n"
-    "\n"
-    "  # Create a default_optimization config that forwards to one of a set\n"
-    "  # of more specialized configs depending on build flags. This pattern\n"
-    "  # is useful because it allows a target to opt in to either a default\n"
-    "  # set, or a more specific set, while avoid duplicating the settings in\n"
-    "  # two places.\n"
-    "  config(\"super_optimization\") {\n"
-    "    cflags = [ ... ]\n"
-    "  }\n"
-    "  config(\"default_optimization\") {\n"
-    "    if (optimize_everything) {\n"
-    "      configs = [ \":super_optimization\" ]\n"
-    "    } else {\n"
-    "      configs = [ \":no_optimization\" ]\n"
-    "    }\n"
-    "  }\n";
+R"(
+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" ]
+    }
+  }
+)";
 
 const char kConsole[] = "console";
 const char kConsole_HelpShort[] =
     "console: [boolean] Run this action in the console pool.";
 const char kConsole_Help[] =
-    "console: Run this action in the console pool.\n"
-    "\n"
-    "  Boolean. Defaults to false.\n"
-    "\n"
-    "  Actions marked \"console = true\" will be run in the built-in ninja\n"
-    "  \"console\" pool. They will have access to real stdin and stdout, and\n"
-    "  output will not be buffered by ninja. This can be useful for\n"
-    "  long-running actions with progress logs, or actions that require user \n"
-    "  input.\n"
-    "\n"
-    "  Only one console pool target can run at any one time in Ninja. Refer\n"
-    "  to the Ninja documentation on the console pool for more info.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  action(\"long_action_with_progress_logs\") {\n"
-    "    console = true\n"
-    "  }\n";
+    R"(console: Run this action in the console pool.
+
+  Boolean. Defaults to false.
+
+  Actions marked "console = true" will be run in the built-in ninja "console"
+  pool. They will have access to real stdin and stdout, and output will not be
+  buffered by ninja. This can be useful for long-running actions with progress
+  logs, or actions that require user input.
+
+  Only one console pool target can run at any one time in Ninja. Refer to the
+  Ninja documentation on the console pool for more info.
+
+Example
+
+  action("long_action_with_progress_logs") {
+    console = true
+  }
+)";
 
 const char kData[] = "data";
 const char kData_HelpShort[] =
     "data: [file list] Runtime data file dependencies.";
 const char kData_Help[] =
-    "data: Runtime data file dependencies.\n"
-    "\n"
-    "  Lists files or directories required to run the given target. These are\n"
-    "  typically data files or directories of data files. The paths are\n"
-    "  interpreted as being relative to the current build file. Since these\n"
-    "  are runtime dependencies, they do not affect which targets are built\n"
-    "  or when. To declare input files to a script, use \"inputs\".\n"
-    "\n"
-    "  Appearing in the \"data\" section does not imply any special handling\n"
-    "  such as copying them to the output directory. This is just used for\n"
-    "  declaring runtime dependencies. Runtime dependencies can be queried\n"
-    "  using the \"runtime_deps\" category of \"gn desc\" or written during\n"
-    "  build generation via \"--runtime-deps-list-file\".\n"
-    "\n"
-    "  GN doesn't require data files to exist at build-time. So actions that\n"
-    "  produce files that are in turn runtime dependencies can list those\n"
-    "  generated files both in the \"outputs\" list as well as the \"data\"\n"
-    "  list.\n"
-    "\n"
-    "  By convention, directories are listed with a trailing slash:\n"
-    "    data = [ \"test/data/\" ]\n"
-    "  However, no verification is done on these so GN doesn't enforce this.\n"
-    "  The paths are just rebased and passed along when requested.\n"
-    "\n"
-    "  Note: On iOS and OS X, create_bundle targets will not be recursed\n"
-    "  into when gathering data. See \"gn help create_bundle\" for details.\n"
-    "\n"
-    "  See \"gn help runtime_deps\" for how these are used.\n";
+    R"(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 OS X, 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.
+)";
 
 const char kDataDeps[] = "data_deps";
 const char kDataDeps_HelpShort[] =
     "data_deps: [label list] Non-linked dependencies.";
 const char kDataDeps_Help[] =
-    "data_deps: Non-linked dependencies.\n"
-    "\n"
-    "  A list of target labels.\n"
-    "\n"
-    "  Specifies dependencies of a target that are not actually linked into\n"
-    "  the current target. Such dependencies will be built and will be\n"
-    "  available at runtime.\n"
-    "\n"
-    "  This is normally used for things like plugins or helper programs that\n"
-    "  a target needs at runtime.\n"
-    "\n"
-    "  Note: On iOS and OS X, create_bundle targets will not be recursed\n"
-    "  into when gathering data_deps. See \"gn help create_bundle\" for\n"
-    "  details.\n"
-    "\n"
-    "  See also \"gn help deps\" and \"gn help data\".\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  executable(\"foo\") {\n"
-    "    deps = [ \"//base\" ]\n"
-    "    data_deps = [ \"//plugins:my_runtime_plugin\" ]\n"
-    "  }\n";
+    R"(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 OS X, 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" ]
+  }
+)";
 
 const char kDefines[] = "defines";
 const char kDefines_HelpShort[] =
     "defines: [string list] C preprocessor defines.";
 const char kDefines_Help[] =
-    "defines: C preprocessor defines.\n"
-    "\n"
-    "  A list of strings\n"
-    "\n"
-    "  These strings will be passed to the C/C++ compiler as #defines. The\n"
-    "  strings may or may not include an \"=\" to assign a value.\n"
+    R"(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.
+)"
     COMMON_ORDERING_HELP
-    "\n"
-    "Example\n"
-    "\n"
-    "  defines = [ \"AWESOME_FEATURE\", \"LOG_LEVEL=3\" ]\n";
+R"(
+Example
+
+  defines = [ "AWESOME_FEATURE", "LOG_LEVEL=3" ]
+)";
 
 const char kDepfile[] = "depfile";
 const char kDepfile_HelpShort[] =
     "depfile: [string] File name for input dependencies for actions.";
 const char kDepfile_Help[] =
-    "depfile: [string] File name for input dependencies for actions.\n"
-    "\n"
-    "  If nonempty, this string specifies that the current action or\n"
-    "  action_foreach target will generate the given \".d\" file containing\n"
-    "  the dependencies of the input. Empty or unset means that the script\n"
-    "  doesn't generate the files.\n"
-    "\n"
-    "  A depfile should be used only when a target depends on files that are\n"
-    "  not already specified by a target's inputs and sources. Likewise,\n"
-    "  depfiles should specify only those dependencies not already included\n"
-    "  in sources or inputs.\n"
-    "\n"
-    "  The .d file should go in the target output directory. If you have more\n"
-    "  than one source file that the script is being run over, you can use\n"
-    "  the output file expansions described in \"gn help action_foreach\" to\n"
-    "  name the .d file according to the input."
-    "\n"
-    "  The format is that of a Makefile and all paths must be relative to the\n"
-    "  root build directory. Only one output may be listed and it must match\n"
-    "  the first output of the action.\n"
-    "\n"
-    "  Although depfiles are created by an action, they should not be listed\n"
-    "  in the action's \"outputs\" unless another target will use the file as\n"
-    "  an input.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  action_foreach(\"myscript_target\") {\n"
-    "    script = \"myscript.py\"\n"
-    "    sources = [ ... ]\n"
-    "\n"
-    "    # Locate the depfile in the output directory named like the\n"
-    "    # inputs but with a \".d\" appended.\n"
-    "    depfile = \"$relative_target_output_dir/{{source_name}}.d\"\n"
-    "\n"
-    "    # Say our script uses \"-o <d file>\" to indicate the depfile.\n"
-    "    args = [ \"{{source}}\", \"-o\", depfile ]\n"
-    "  }\n";
+    R"(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 ]
+  }
+)";
 
 const char kDeps[] = "deps";
 const char kDeps_HelpShort[] =
     "deps: [label list] Private linked dependencies.";
 const char kDeps_Help[] =
-    "deps: Private linked dependencies.\n"
-    "\n"
-    "  A list of target labels.\n"
-    "\n"
-    "  Specifies private dependencies of a target. Private dependencies are\n"
-    "  propagated up the dependency tree and linked to dependant targets, but\n"
-    "  do not grant the ability to include headers from the dependency.\n"
-    "  Public configs are not forwarded.\n"
-    "\n"
-    "Details of dependency propagation\n"
-    "\n"
-    "  Source sets, shared libraries, and non-complete static libraries\n"
-    "  will be propagated up the dependency tree across groups, non-complete\n"
-    "  static libraries and source sets.\n"
-    "\n"
-    "  Executables, shared libraries, and complete static libraries will\n"
-    "  link all propagated targets and stop propagation. Actions and copy\n"
-    "  steps also stop propagation, allowing them to take a library as an\n"
-    "  input but not force dependants to link to it.\n"
-    "\n"
-    "  Propagation of all_dependent_configs and public_configs happens\n"
-    "  independently of target type. all_dependent_configs are always\n"
-    "  propagated across all types of targets, and public_configs\n"
-    "  are always propagated across public deps of all types of targets.\n"
-    "\n"
-    "  Data dependencies are propagated differently. See\n"
-    "  \"gn help data_deps\" and \"gn help runtime_deps\".\n"
-    "\n"
-    "  See also \"public_deps\".\n";
+    R"(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 dependant 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
+  dependants 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".
+)";
 
 const char kIncludeDirs[] = "include_dirs";
 const char kIncludeDirs_HelpShort[] =
     "include_dirs: [directory list] Additional include directories.";
 const char kIncludeDirs_Help[] =
-    "include_dirs: Additional include directories.\n"
-    "\n"
-    "  A list of source directories.\n"
-    "\n"
-    "  The directories in this list will be added to the include path for\n"
-    "  the files in the affected target.\n"
+    R"(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.
+)"
     COMMON_ORDERING_HELP
-    "\n"
-    "Example\n"
-    "\n"
-    "  include_dirs = [ \"src/include\", \"//third_party/foo\" ]\n";
+R"(
+Example
+
+  include_dirs = [ "src/include", "//third_party/foo" ]
+)";
 
 const char kInputs[] = "inputs";
 const char kInputs_HelpShort[] =
     "inputs: [file list] Additional compile-time dependencies.";
 const char kInputs_Help[] =
-    "inputs: Additional compile-time dependencies.\n"
-    "\n"
-    "  Inputs are compile-time dependencies of the current target. This means\n"
-    "  that all inputs must be available before compiling any of the sources\n"
-    "  or executing any actions.\n"
-    "\n"
-    "  Inputs are typically only used for action and action_foreach targets.\n"
-    "\n"
-    "Inputs for actions\n"
-    "\n"
-    "  For action and action_foreach targets, inputs should be the inputs to\n"
-    "  script that don't vary. These should be all .py files that the script\n"
-    "  uses via imports (the main script itself will be an implicit dependency"
-                                                                            "\n"
-    "  of the action so need not be listed).\n"
-    "\n"
-    "  For action targets, inputs and sources are treated the same, but from\n"
-    "  a style perspective, it's recommended to follow the same rule as\n"
-    "  action_foreach and put helper files in the inputs, and the data used\n"
-    "  by the script (if any) in sources.\n"
-    "\n"
-    "  Note that another way to declare input dependencies from an action\n"
-    "  is to have the action write a depfile (see \"gn help depfile\"). This\n"
-    "  allows the script to dynamically write input dependencies, that might\n"
-    "  not be known until actually executing the script. This is more\n"
-    "  efficient than doing processing while running GN to determine the\n"
-    "  inputs, and is easier to keep in-sync than hardcoding the list.\n"
-    "\n"
-    "Script input gotchas\n"
-    "\n"
-    "  It may be tempting to write a script that enumerates all files in a\n"
-    "  directory as inputs. Don't do this! Even if you specify all the files\n"
-    "  in the inputs or sources in the GN target (or worse, enumerate the\n"
-    "  files in an exec_script call when running GN, which will be slow), the\n"
-    "  dependencies will be broken.\n"
-    "\n"
-    "  The problem happens if a file is ever removed because the inputs are\n"
-    "  not listed on the command line to the script. Because the script\n"
-    "  hasn't changed and all inputs are up to date, the script will not\n"
-    "  re-run and you will get a stale build. Instead, either list all\n"
-    "  inputs on the command line to the script, or if there are many, create\n"
-    "  a separate list file that the script reads. As long as this file is\n"
-    "  listed in the inputs, the build will detect when it has changed in any\n"
-    "  way and the action will re-run.\n"
-    "\n"
-    "Inputs for binary targets\n"
-    "\n"
-    "  Any input dependencies will be resolved before compiling any sources.\n"
-    "  Normally, all actions that a target depends on will be run before any\n"
-    "  files in a target are compiled. So if you depend on generated headers,\n"
-    "  you do not typically need to list them in the inputs section.\n"
-    "\n"
-    "  Inputs for binary targets will be treated as implicit dependencies,\n"
-    "  meaning that changes in any of the inputs will force all sources in\n"
-    "  the target to be recompiled. If an input only applies to a subset of\n"
-    "  source files, you may want to split those into a separate target to\n"
-    "  avoid unnecessary recompiles.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  action(\"myscript\") {\n"
-    "    script = \"domything.py\"\n"
-    "    inputs = [ \"input.data\" ]\n"
-    "  }\n";
+    R"(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" ]
+  }
+)";
 
 const char kLdflags[] = "ldflags";
 const char kLdflags_HelpShort[] =
     "ldflags: [string list] Flags passed to the linker.";
 const char kLdflags_Help[] =
-    "ldflags: Flags passed to the linker.\n"
-    "\n"
-    "  A list of strings.\n"
-    "\n"
-    "  These flags are passed on the command-line to the linker and generally\n"
-    "  specify various linking options. Most targets will not need these and\n"
-    "  will use \"libs\" and \"lib_dirs\" instead.\n"
-    "\n"
-    "  ldflags are NOT pushed to dependents, so applying ldflags to source\n"
-    "  sets or static libraries will be a no-op. If you want to apply ldflags\n"
-    "  to dependent targets, put them in a config and set it in the\n"
-    "  all_dependent_configs or public_configs.\n"
+    R"(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.
+)"
     COMMON_ORDERING_HELP;
 
 #define COMMON_LIB_INHERITANCE_HELP \
@@ -1212,597 +1226,602 @@
 const char kLibDirs_HelpShort[] =
     "lib_dirs: [directory list] Additional library directories.";
 const char kLibDirs_Help[] =
-    "lib_dirs: Additional library directories.\n"
-    "\n"
-    "  A list of directories.\n"
-    "\n"
-    "  Specifies additional directories passed to the linker for searching\n"
-    "  for the required libraries. If an item is not an absolute path, it\n"
-    "  will be treated as being relative to the current build file.\n"
+    R"(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.
+)"
     COMMON_LIB_INHERITANCE_HELP
     COMMON_ORDERING_HELP
     LIBS_AND_LIB_DIRS_ORDERING_HELP
-    "\n"
-    "Example\n"
-    "\n"
-    "  lib_dirs = [ \"/usr/lib/foo\", \"lib/doom_melon\" ]\n";
+R"(
+Example
+
+  lib_dirs = [ "/usr/lib/foo", "lib/doom_melon" ]
+)";
 
 const char kLibs[] = "libs";
 const char kLibs_HelpShort[] =
     "libs: [string list] Additional libraries to link.";
 const char kLibs_Help[] =
-    "libs: Additional libraries to link.\n"
-    "\n"
-    "  A list of library names or library paths.\n"
-    "\n"
-    "  These libraries will be linked into the final binary (executable or\n"
-    "  shared library) containing the current target.\n"
+    R"(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.
+)"
     COMMON_LIB_INHERITANCE_HELP
-    "\n"
-    "Types of libs\n"
-    "\n"
-    "  There are several different things that can be expressed in libs:\n"
-    "\n"
-    "  File paths\n"
-    "      Values containing '/' will be treated as references to files in\n"
-    "      the checkout. They will be rebased to be relative to the build\n"
-    "      directory and specified in the \"libs\" for linker tools. This\n"
-    "      facility should be used for libraries that are checked in to the\n"
-    "      version control. For libraries that are generated by the build,\n"
-    "      use normal GN deps to link them.\n"
-    "\n"
-    "  System libraries\n"
-    "      Values not containing '/' will be treated as system library names.\n"
-    "      These will be passed unmodified to the linker and prefixed with\n"
-    "      the \"lib_prefix\" attribute of the linker tool. Generally you\n"
-    "      would set the \"lib_dirs\" so the given library is found. Your\n"
-    "      BUILD.gn file should not specify the switch (like \"-l\"): this\n"
-    "      will be encoded in the \"lib_prefix\" of the tool.\n"
-    "\n"
-    "  Apple frameworks\n"
-    "      System libraries ending in \".framework\" will be special-cased:\n"
-    "      the switch \"-framework\" will be prepended instead of the\n"
-    "      lib_prefix, and the \".framework\" suffix will be trimmed. This is\n"
-    "      to support the way Mac links framework dependencies.\n"
+R"(
+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_prefix" 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_prefix"
+      of the tool.
+
+  Apple frameworks
+      System libraries ending in ".framework" will be special-cased: the switch
+      "-framework" will be prepended instead of the lib_prefix, and the
+      ".framework" suffix will be trimmed. This is to support the way Mac links
+      framework dependencies.
+)"
     COMMON_ORDERING_HELP
     LIBS_AND_LIB_DIRS_ORDERING_HELP
-    "\n"
-    "Examples\n"
-    "\n"
-    "  On Windows:\n"
-    "    libs = [ \"ctl3d.lib\" ]\n"
-    "\n"
-    "  On Linux:\n"
-    "    libs = [ \"ld\" ]\n";
+R"(
+Examples
+
+  On Windows:
+    libs = [ "ctl3d.lib" ]
+
+  On Linux:
+    libs = [ "ld" ]
+)";
 
 const char kOutputExtension[] = "output_extension";
 const char kOutputExtension_HelpShort[] =
     "output_extension: [string] Value to use for the output's file extension.";
 const char kOutputExtension_Help[] =
-    "output_extension: Value to use for the output's file extension.\n"
-    "\n"
-    "  Normally the file extension for a target is based on the target\n"
-    "  type and the operating system, but in rare cases you will need to\n"
-    "  override the name (for example to use \"libfreetype.so.6\" instead\n"
-    "  of libfreetype.so on Linux).\n"
-    "\n"
-    "  This value should not include a leading dot. If undefined, the default\n"
-    "  specified on the tool will be used. If set to the empty string, no\n"
-    "  output extension will be used.\n"
-    "\n"
-    "  The output_extension will be used to set the \"{{output_extension}}\"\n"
-    "  expansion which the linker tool will generally use to specify the\n"
-    "  output file name. See \"gn help tool\".\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  shared_library(\"freetype\") {\n"
-    "    if (is_linux) {\n"
-    "      # Call the output \"libfreetype.so.6\"\n"
-    "      output_extension = \"so.6\"\n"
-    "    }\n"
-    "    ...\n"
-    "  }\n"
-    "\n"
-    "  # On Windows, generate a \"mysettings.cpl\" control panel applet.\n"
-    "  # Control panel applets are actually special shared libraries.\n"
-    "  if (is_win) {\n"
-    "    shared_library(\"mysettings\") {\n"
-    "      output_extension = \"cpl\"\n"
-    "      ...\n"
-    "    }\n"
-    "  }\n";
+    R"(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"
+      ...
+    }
+  }
+)";
 
 const char kOutputDir[] = "output_dir";
 const char kOutputDir_HelpShort[] =
     "output_dir: [directory] Directory to put output file in.";
 const char kOutputDir_Help[] =
-    "output_dir: [directory] Directory to put output file in.\n"
-    "\n"
-    "  For library and executable targets, overrides the directory for the\n"
-    "  final output. This must be in the root_build_dir or a child thereof.\n"
-    "\n"
-    "  This should generally be in the root_out_dir or a subdirectory thereof\n"
-    "  (the root_out_dir will be the same as the root_build_dir for the\n"
-    "  default toolchain, and will be a subdirectory for other toolchains).\n"
-    "  Not putting the output in a subdirectory of root_out_dir can result\n"
-    "  in collisions between different toolchains, so you will need to take\n"
-    "  steps to ensure that your target is only present in one toolchain.\n"
-    "\n"
-    "  Normally the toolchain specifies the output directory for libraries\n"
-    "  and executables (see \"gn help tool\"). You will have to consult that\n"
-    "  for the default location. The default location will be used if\n"
-    "  output_dir is undefined or empty.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  shared_library(\"doom_melon\") {\n"
-    "    output_dir = \"$root_out_dir/plugin_libs\"\n"
-    "    ...\n"
-    "  }\n";
+    R"(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"
+    ...
+  }
+)";
 
 const char kOutputName[] = "output_name";
 const char kOutputName_HelpShort[] =
     "output_name: [string] Name for the output file other than the default.";
 const char kOutputName_Help[] =
-    "output_name: Define a name for the output file other than the default.\n"
-    "\n"
-    "  Normally the output name of a target will be based on the target name,\n"
-    "  so the target \"//foo/bar:bar_unittests\" will generate an output\n"
-    "  file such as \"bar_unittests.exe\" (using Windows as an example).\n"
-    "\n"
-    "  Sometimes you will want an alternate name to avoid collisions or\n"
-    "  if the internal name isn't appropriate for public distribution.\n"
-    "\n"
-    "  The output name should have no extension or prefixes, these will be\n"
-    "  added using the default system rules. For example, on Linux an output\n"
-    "  name of \"foo\" will produce a shared library \"libfoo.so\". There\n"
-    "  is no way to override the output prefix of a linker tool on a per-\n"
-    "  target basis. If you need more flexibility, create a copy target\n"
-    "  to produce the file you want.\n"
-    "\n"
-    "  This variable is valid for all binary output target types.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  static_library(\"doom_melon\") {\n"
-    "    output_name = \"fluffy_bunny\"\n"
-    "  }\n";
+    R"(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"
+  }
+)";
 
 const char kOutputPrefixOverride[] = "output_prefix_override";
 const char kOutputPrefixOverride_HelpShort[] =
     "output_prefix_override: [boolean] Don't use prefix for output name.";
 const char kOutputPrefixOverride_Help[] =
-    "output_prefix_override: Don't use prefix for output name.\n"
-    "\n"
-    "  A boolean that overrides the output prefix for a target. Defaults to\n"
-    "  false.\n"
-    "\n"
-    "  Some systems use prefixes for the names of the final target output\n"
-    "  file. The normal example is \"libfoo.so\" on Linux for a target\n"
-    "  named \"foo\".\n"
-    "\n"
-    "  The output prefix for a given target type is specified on the linker\n"
-    "  tool (see \"gn help tool\"). Sometimes this prefix is undesired.\n"
-    "\n"
-    "  See also \"gn help output_extension\".\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  shared_library(\"doom_melon\") {\n"
-    "    # Normally this will produce \"libdoom_melon.so\" on Linux, setting\n"
-    "    # Setting this flag will produce \"doom_melon.so\".\n"
-    "    output_prefix_override = true\n"
-    "    ...\n"
-    "  }\n";
+    R"(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
+    ...
+  }
+)";
 
 const char kOutputs[] = "outputs";
 const char kOutputs_HelpShort[] =
     "outputs: [file list] Output files for actions and copy targets.";
 const char kOutputs_Help[] =
-    "outputs: Output files for actions and copy targets.\n"
-    "\n"
-    "  Outputs is valid for \"copy\", \"action\", and \"action_foreach\"\n"
-    "  target types and indicates the resulting files. Outputs must always\n"
-    "  refer to files in the build directory.\n"
-    "\n"
-    "  copy\n"
-    "    Copy targets should have exactly one entry in the outputs list. If\n"
-    "    there is exactly one source, this can be a literal file name or a\n"
-    "    source expansion. If there is more than one source, this must\n"
-    "    contain a source expansion to map a single input name to a single\n"
-    "    output name. See \"gn help copy\".\n"
-    "\n"
-    "  action_foreach\n"
-    "    Action_foreach targets must always use source expansions to map\n"
-    "    input files to output files. There can be more than one output,\n"
-    "    which means that each invocation of the script will produce a set of\n"
-    "    files (presumably based on the name of the input file). See\n"
-    "    \"gn help action_foreach\".\n"
-    "\n"
-    "  action\n"
-    "    Action targets (excluding action_foreach) must list literal output\n"
-    "    file(s) with no source expansions. See \"gn help action\".\n";
+    R"(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".
+)";
 
 const char kPrecompiledHeader[] = "precompiled_header";
 const char kPrecompiledHeader_HelpShort[] =
     "precompiled_header: [string] Header file to precompile.";
 const char kPrecompiledHeader_Help[] =
-    "precompiled_header: [string] Header file to precompile.\n"
-    "\n"
-    "  Precompiled headers will be used when a target specifies this\n"
-    "  value, or a config applying to this target specifies this value.\n"
-    "  In addition, the tool corresponding to the source files must also\n"
-    "  specify precompiled headers (see \"gn help tool\"). The tool\n"
-    "  will also specify what type of precompiled headers to use.\n"
-    "\n"
-    "  The precompiled header/source variables can be specified on a target\n"
-    "  or a config, but must be the same for all configs applying to a given\n"
-    "  target since a target can only have one precompiled header.\n"
-    "\n"
-    "MSVC precompiled headers\n"
-    "\n"
-    "  When using MSVC-style precompiled headers, the \"precompiled_header\"\n"
-    "  value is a string corresponding to the header. This is NOT a path\n"
-    "  to a file that GN recognises, but rather the exact string that appears\n"
-    "  in quotes after an #include line in source code. The compiler will\n"
-    "  match this string against includes or forced includes (/FI).\n"
-    "\n"
-    "  MSVC also requires a source file to compile the header with. This must\n"
-    "  be specified by the \"precompiled_source\" value. In contrast to the\n"
-    "  header value, this IS a GN-style file name, and tells GN which source\n"
-    "  file to compile to make the .pch file used for subsequent compiles.\n"
-    "\n"
-    "  If you use both C and C++ sources, the precompiled header and source\n"
-    "  file will be compiled using both tools. You will want to make sure\n"
-    "  to wrap C++ includes in __cplusplus #ifdefs so the file will compile\n"
-    "  in C mode.\n"
-    "\n"
-    "  For example, if the toolchain specifies MSVC headers:\n"
-    "\n"
-    "    toolchain(\"vc_x64\") {\n"
-    "      ...\n"
-    "      tool(\"cxx\") {\n"
-    "        precompiled_header_type = \"msvc\"\n"
-    "        ...\n"
-    "\n"
-    "  You might make a config like this:\n"
-    "\n"
-    "    config(\"use_precompiled_headers\") {\n"
-    "      precompiled_header = \"build/precompile.h\"\n"
-    "      precompiled_source = \"//build/precompile.cc\"\n"
-    "\n"
-    "      # Either your source files should #include \"build/precompile.h\"\n"
-    "      # first, or you can do this to force-include the header.\n"
-    "      cflags = [ \"/FI$precompiled_header\" ]\n"
-    "    }\n"
-    "\n"
-    "  And then define a target that uses the config:\n"
-    "\n"
-    "    executable(\"doom_melon\") {\n"
-    "      configs += [ \":use_precompiled_headers\" ]\n"
-    "      ...\n"
-    "\n";
+    R"(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.
+
+  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.
+
+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.
+
+  If you use both C and C++ sources, the precompiled header and source file
+  will be compiled using both tools. You will want to make sure to wrap C++
+  includes in __cplusplus #ifdefs so the file will compile in C mode.
+
+  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" ]
+      ...
+)";
 
 const char kPrecompiledSource[] = "precompiled_source";
 const char kPrecompiledSource_HelpShort[] =
     "precompiled_source: [file name] Source file to precompile.";
 const char kPrecompiledSource_Help[] =
-    "precompiled_source: [file name] Source file to precompile.\n"
-    "\n"
-    "  The source file that goes along with the precompiled_header when\n"
-    "  using \"msvc\"-style precompiled headers. It will be implicitly added\n"
-    "  to the sources of the target. See \"gn help precompiled_header\".\n";
+    R"(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".
+)";
 
 const char kProductType[] = "product_type";
 const char kProductType_HelpShort[] =
     "product_type: [string] Product type for Xcode projects.";
 const char kProductType_Help[] =
-    "product_type: Product type for Xcode projects.\n"
-    "\n"
-    "  Correspond to the type of the product of a create_bundle target. Only\n"
-    "  meaningful to Xcode (used as part of the Xcode project generation).\n"
-    "\n"
-    "  When generating Xcode project files, only create_bundle target with\n"
-    "  a non-empty product_type will have a corresponding target in Xcode\n"
-    "  project.\n";
+    R"(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.
+)";
 
 const char kPublic[] = "public";
 const char kPublic_HelpShort[] =
     "public: [file list] Declare public header files for a target.";
 const char kPublic_Help[] =
-    "public: Declare public header files for a target.\n"
-    "\n"
-    "  A list of files that other targets can include. These permissions are\n"
-    "  checked via the \"check\" command (see \"gn help check\").\n"
-    "\n"
-    "  If no public files are declared, other targets (assuming they have\n"
-    "  visibility to depend on this target can include any file in the\n"
-    "  sources list. If this variable is defined on a target, dependent\n"
-    "  targets may only include files on this whitelist.\n"
-    "\n"
-    "  Header file permissions are also subject to visibility. A target\n"
-    "  must be visible to another target to include any files from it at all\n"
-    "  and the public headers indicate which subset of those files are\n"
-    "  permitted. See \"gn help visibility\" for more.\n"
-    "\n"
-    "  Public files are inherited through the dependency tree. So if there is\n"
-    "  a dependency A -> B -> C, then A can include C's public headers.\n"
-    "  However, the same is NOT true of visibility, so unless A is in C's\n"
-    "  visibility list, the include will be rejected.\n"
-    "\n"
-    "  GN only knows about files declared in the \"sources\" and \"public\"\n"
-    "  sections of targets. If a file is included that is not known to the\n"
-    "  build, it will be allowed.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  These exact files are public:\n"
-    "    public = [ \"foo.h\", \"bar.h\" ]\n"
-    "\n"
-    "  No files are public (no targets may include headers from this one):\n"
-    "    public = []\n";
+    R"(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.
+
+  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.
+
+Examples
+
+  These exact files are public:
+    public = [ "foo.h", "bar.h" ]
+
+  No files are public (no targets may include headers from this one):
+    public = []
+)";
 
 const char kPublicConfigs[] = "public_configs";
 const char kPublicConfigs_HelpShort[] =
     "public_configs: [label list] Configs applied to dependents.";
 const char kPublicConfigs_Help[] =
-    "public_configs: Configs to be applied on dependents.\n"
-    "\n"
-    "  A list of config labels.\n"
-    "\n"
-    "  Targets directly depending on this one will have the configs listed in\n"
-    "  this variable added to them. These configs will also apply to the\n"
-    "  current target.\n"
-    "\n"
-    "  This addition happens in a second phase once a target and all of its\n"
-    "  dependencies have been resolved. Therefore, a target will not see\n"
-    "  these force-added configs in their \"configs\" variable while the\n"
-    "  script is running, and then can not be removed. As a result, this\n"
-    "  capability should generally only be used to add defines and include\n"
-    "  directories necessary to compile a target's headers.\n"
-    "\n"
-    "  See also \"all_dependent_configs\".\n"
+    R"(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 then 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".
+)"
     COMMON_ORDERING_HELP;
 
 const char kPublicDeps[] = "public_deps";
 const char kPublicDeps_HelpShort[] =
     "public_deps: [label list] Declare public dependencies.";
 const char kPublicDeps_Help[] =
-    "public_deps: Declare public dependencies.\n"
-    "\n"
-    "  Public dependencies are like private dependencies (see\n"
-    "  \"gn help deps\") but additionally express that the current target\n"
-    "  exposes the listed deps as part of its public API.\n"
-    "\n"
-    "  This has several ramifications:\n"
-    "\n"
-    "    - public_configs that are part of the dependency are forwarded\n"
-    "      to direct dependents.\n"
-    "\n"
-    "    - Public headers in the dependency are usable by dependents\n"
-    "      (includes do not require a direct dependency or visibility).\n"
-    "\n"
-    "    - If the current target is a shared library, other shared libraries\n"
-    "      that it publicly depends on (directly or indirectly) are\n"
-    "      propagated up the dependency tree to dependents for linking.\n"
-    "\n"
-    "Discussion\n"
-    "\n"
-    "  Say you have three targets: A -> B -> C. C's visibility may allow\n"
-    "  B to depend on it but not A. Normally, this would prevent A from\n"
-    "  including any headers from C, and C's public_configs would apply\n"
-    "  only to B.\n"
-    "\n"
-    "  If B lists C in its public_deps instead of regular deps, A will now\n"
-    "  inherit C's public_configs and the ability to include C's public\n"
-    "  headers.\n"
-    "\n"
-    "  Generally if you are writing a target B and you include C's headers\n"
-    "  as part of B's public headers, or targets depending on B should\n"
-    "  consider B and C to be part of a unit, you should use public_deps\n"
-    "  instead of deps.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  # This target can include files from \"c\" but not from\n"
-    "  # \"super_secret_implementation_details\".\n"
-    "  executable(\"a\") {\n"
-    "    deps = [ \":b\" ]\n"
-    "  }\n"
-    "\n"
-    "  shared_library(\"b\") {\n"
-    "    deps = [ \":super_secret_implementation_details\" ]\n"
-    "    public_deps = [ \":c\" ]\n"
-    "  }\n";
+    R"(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" ]
+  }
+)";
 
 const char kResponseFileContents[] = "response_file_contents";
 const char kResponseFileContents_HelpShort[] =
     "response_file_contents: [string list] Contents of .rsp file for actions.";
 const char kResponseFileContents_Help[] =
-    "response_file_contents: Contents of a response file for actions.\n"
-    "\n"
-    "  Sometimes the arguments passed to a script can be too long for the\n"
-    "  system's command-line capabilities. This is especially the case on\n"
-    "  Windows where the maximum command-line length is less than 8K. A\n"
-    "  response file allows you to pass an unlimited amount of data to a\n"
-    "  script in a temporary file for an action or action_foreach target.\n"
-    "\n"
-    "  If the response_file_contents variable is defined and non-empty, the\n"
-    "  list will be treated as script args (including possibly substitution\n"
-    "  patterns) that will be written to a temporary file at build time.\n"
-    "  The name of the temporary file will be substituted for\n"
-    "  \"{{response_file_name}}\" in the script args.\n"
-    "\n"
-    "  The response file contents will always be quoted and escaped\n"
-    "  according to Unix shell rules. To parse the response file, the Python\n"
-    "  script should use \"shlex.split(file_contents)\".\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  action(\"process_lots_of_files\") {\n"
-    "    script = \"process.py\",\n"
-    "    inputs = [ ... huge list of files ... ]\n"
-    "\n"
-    "    # Write all the inputs to a response file for the script. Also,\n"
-    "    # make the paths relative to the script working directory.\n"
-    "    response_file_contents = rebase_path(inputs, root_build_dir)\n"
-    "\n"
-    "    # The script expects the name of the response file in --file-list.\n"
-    "    args = [\n"
-    "      \"--enable-foo\",\n"
-    "      \"--file-list={{response_file_name}}\",\n"
-    "    ]\n"
-    "  }\n";
+   R"*(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}}",
+    ]
+  }
+)*";
 
 const char kScript[] = "script";
 const char kScript_HelpShort[] =
     "script: [file name] Script file for actions.";
 const char kScript_Help[] =
-    "script: Script file for actions.\n"
-    "\n"
-    "  An absolute or buildfile-relative file name of a Python script to run\n"
-    "  for a action and action_foreach targets (see \"gn help action\" and\n"
-    "  \"gn help action_foreach\").\n";
+    R"(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").
+)";
 
 const char kSources[] = "sources";
 const char kSources_HelpShort[] =
     "sources: [file list] Source files for a target.";
 const char kSources_Help[] =
-    "sources: Source files for a target\n"
-    "\n"
-    "  A list of files. Non-absolute paths will be resolved relative to the\n"
-    "  current build file.\n"
-    "\n"
-    "Sources for binary targets\n"
-    "\n"
-    "  For binary targets (source sets, executables, and libraries), the\n"
-    "  known file types will be compiled with the associated tools. Unknown\n"
-    "  file types and headers will be skipped. However, you should still\n"
-    "  list all C/C+ header files so GN knows about the existance of those\n"
-    "  files for the purposes of include checking.\n"
-    "\n"
-    "  As a special case, a file ending in \".def\" will be treated as a\n"
-    "  Windows module definition file. It will be appended to the link\n"
-    "  line with a preceeding \"/DEF:\" string. There must be at most one\n"
-    "  .def file in a target and they do not cross dependency boundaries\n"
-    "  (so specifying a .def file in a static library or source set will have\n"
-    "  no effect on the executable or shared library they're linked into).\n"
-    "\n"
-    "Sources for non-binary targets\n"
-    "\n"
-    "  action_foreach\n"
-    "    The sources are the set of files that the script will be executed\n"
-    "    over. The script will run once per file.\n"
-    "\n"
-    "  action\n"
-    "    The sources will be treated the same as inputs. See "
-         "\"gn help inputs\"\n"
-    "    for more information and usage advice.\n"
-    "\n"
-    "  copy\n"
-    "    The source are the source files to copy.\n";
+    R"(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 existance 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
+  preceeding "/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.
+)";
 
 const char kTestonly[] = "testonly";
 const char kTestonly_HelpShort[] =
     "testonly: [boolean] Declares a target must only be used for testing.";
 const char kTestonly_Help[] =
-    "testonly: Declares a target must only be used for testing.\n"
-    "\n"
-    "  Boolean. Defaults to false.\n"
-    "\n"
-    "  When a target is marked \"testonly = true\", it must only be depended\n"
-    "  on by other test-only targets. Otherwise, GN will issue an error\n"
-    "  that the depenedency is not allowed.\n"
-    "\n"
-    "  This feature is intended to prevent accidentally shipping test code\n"
-    "  in a final product.\n"
-    "\n"
-    "Example\n"
-    "\n"
-    "  source_set(\"test_support\") {\n"
-    "    testonly = true\n"
-    "    ...\n"
-    "  }\n";
+    R"(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
+    ...
+  }
+)";
 
 const char kVisibility[] = "visibility";
 const char kVisibility_HelpShort[] =
     "visibility: [label list] A list of labels that can depend on a target.";
 const char kVisibility_Help[] =
-    "visibility: A list of labels that can depend on a target.\n"
-    "\n"
-    "  A list of labels and label patterns that define which targets can\n"
-    "  depend on the current one. These permissions are checked via the\n"
-    "  \"check\" command (see \"gn help check\").\n"
-    "\n"
-    "  If visibility is not defined, it defaults to public (\"*\").\n"
-    "\n"
-    "  If visibility is defined, only the targets with labels that match it\n"
-    "  can depend on the current target. The empty list means no targets\n"
-    "  can depend on the current target.\n"
-    "\n"
-    "  Tip: Often you will want the same visibility for all targets in a\n"
-    "  BUILD file. In this case you can just put the definition at the top,\n"
-    "  outside of any target, and the targets will inherit that scope and see\n"
-    "  the definition.\n"
-    "\n"
-    "Patterns\n"
-    "\n"
-    "  See \"gn help label_pattern\" for more details on what types of\n"
-    "  patterns are supported. If a toolchain is specified, only targets\n"
-    "  in that toolchain will be matched. If a toolchain is not specified on\n"
-    "  a pattern, targets in all toolchains will be matched.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  Only targets in the current buildfile (\"private\"):\n"
-    "    visibility = [ \":*\" ]\n"
-    "\n"
-    "  No targets (used for targets that should be leaf nodes):\n"
-    "    visibility = []\n"
-    "\n"
-    "  Any target (\"public\", the default):\n"
-    "    visibility = [ \"*\" ]\n"
-    "\n"
-    "  All targets in the current directory and any subdirectory:\n"
-    "    visibility = [ \"./*\" ]\n"
-    "\n"
-    "  Any target in \"//bar/BUILD.gn\":\n"
-    "    visibility = [ \"//bar:*\" ]\n"
-    "\n"
-    "  Any target in \"//bar/\" or any subdirectory thereof:\n"
-    "    visibility = [ \"//bar/*\" ]\n"
-    "\n"
-    "  Just these specific targets:\n"
-    "    visibility = [ \":mything\", \"//foo:something_else\" ]\n"
-    "\n"
-    "  Any target in the current directory and any subdirectory thereof, plus\n"
-    "  any targets in \"//bar/\" and any subdirectory thereof.\n"
-    "    visibility = [ \"./*\", \"//bar/*\" ]\n";
+    R"(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/*" ]
+)";
 
 const char kWriteRuntimeDeps[] = "write_runtime_deps";
 const char kWriteRuntimeDeps_HelpShort[] =
     "write_runtime_deps: Writes the target's runtime_deps to the given path.";
 const char kWriteRuntimeDeps_Help[] =
-    "write_runtime_deps: Writes the target's runtime_deps to the given path.\n"
-    "\n"
-    "  Does not synchronously write the file, but rather schedules it\n"
-    "  to be written at the end of generation.\n"
-    "\n"
-    "  If the file exists and the contents are identical to that being\n"
-    "  written, the file will not be updated. This will prevent unnecessary\n"
-    "  rebuilds of targets that depend on this file.\n"
-    "\n"
-    "  Path must be within the output directory.\n"
-    "\n"
-    "  See \"gn help runtime_deps\" for how the runtime dependencies are\n"
-    "  computed.\n"
-    "\n"
-    "  The format of this file will list one file per line with no escaping.\n"
-    "  The files will be relative to the root_build_dir. The first line of\n"
-    "  the file will be the main output file of the target itself. The file\n"
-    "  contents will be the same as requesting the runtime deps be written on\n"
-    "  the command line (see \"gn help --runtime-deps-list-file\").\n";
+    R"(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").
+)";
 
 // -----------------------------------------------------------------------------