Allow raw string literals and add a sample usage.

This was tentatively approved on the discussion thread two months ago.

BUG=none
TEST=none

Review-Url: https://codereview.chromium.org/2470643002
Cr-Original-Commit-Position: refs/heads/master@{#429402}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: bf8b8103771747ed31d3af4e924de7cd27607deb

tools/gn/args.cc

diff --git a/tools/gn/args.cc b/tools/gn/args.cc
index 72480f5..9f86016 100644
--- a/tools/gn/args.cc
+++ b/tools/gn/args.cc
@@ -9,62 +9,63 @@
 #include "tools/gn/variables.h"
 
 const char kBuildArgs_Help[] =
-    "Build Arguments Overview\n"
-    "\n"
-    "  Build arguments are variables passed in from outside of the build\n"
-    "  that build files can query to determine how the build works.\n"
-    "\n"
-    "How build arguments are set\n"
-    "\n"
-    "  First, system default arguments are set based on the current system.\n"
-    "  The built-in arguments are:\n"
-    "   - host_cpu\n"
-    "   - host_os\n"
-    "   - current_cpu\n"
-    "   - current_os\n"
-    "   - target_cpu\n"
-    "   - target_os\n"
-    "\n"
-    "  If specified, arguments from the --args command line flag are used. If\n"
-    "  that flag is not specified, args from previous builds in the build\n"
-    "  directory will be used (this is in the file args.gn in the build\n"
-    "  directory).\n"
-    "\n"
-    "  Last, for targets being compiled with a non-default toolchain, the\n"
-    "  toolchain overrides are applied. These are specified in the\n"
-    "  toolchain_args section of a toolchain definition. The use-case for\n"
-    "  this is that a toolchain may be building code for a different\n"
-    "  platform, and that it may want to always specify Posix, for example.\n"
-    "  See \"gn help toolchain\" for more.\n"
-    "\n"
-    "  If you specify an override for a build argument that never appears in\n"
-    "  a \"declare_args\" call, a nonfatal error will be displayed.\n"
-    "\n"
-    "Examples\n"
-    "\n"
-    "  gn args out/FooBar\n"
-    "      Create the directory out/FooBar and open an editor. You would type\n"
-    "      something like this into that file:\n"
-    "          enable_doom_melon=false\n"
-    "          os=\"android\"\n"
-    "\n"
-    "  gn gen out/FooBar --args=\"enable_doom_melon=true os=\\\"android\\\"\"\n"
-    "      This will overwrite the build directory with the given arguments.\n"
-    "      (Note that the quotes inside the args command will usually need to\n"
-    "      be escaped for your shell to pass through strings values.)\n"
-    "\n"
-    "How build arguments are used\n"
-    "\n"
-    "  If you want to use an argument, you use declare_args() and specify\n"
-    "  default values. These default values will apply if none of the steps\n"
-    "  listed in the \"How build arguments are set\" section above apply to\n"
-    "  the given argument, but the defaults will not override any of these.\n"
-    "\n"
-    "  Often, the root build config file will declare global arguments that\n"
-    "  will be passed to all buildfiles. Individual build files can also\n"
-    "  specify arguments that apply only to those files. It is also useful\n"
-    "  to specify build args in an \"import\"-ed file if you want such\n"
-    "  arguments to apply to multiple buildfiles.\n";
+    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.
+
+How build arguments are set
+
+  First, system default arguments are set based on the current system.
+  The built-in arguments are:
+   - host_cpu
+   - host_os
+   - current_cpu
+   - current_os
+   - target_cpu
+   - target_os
+
+  If specified, arguments from the --args command line flag are used. If
+  that flag is not specified, args from previous builds in the build
+  directory will be used (this is in the file args.gn in the build
+  directory).
+
+  Last, for targets being compiled with a non-default toolchain, the
+  toolchain overrides are applied. These are specified in the
+  toolchain_args section of a toolchain definition. The use-case for
+  this is that a toolchain may be building code for a different
+  platform, and that it may want to always specify Posix, for example.
+  See "gn help toolchain" for more.
+
+  If you specify an override for a build argument that never appears in
+  a "declare_args" call, a nonfatal error will be displayed.
+
+Examples
+
+  gn args out/FooBar
+      Create the directory out/FooBar and open an editor. You would type
+      something like this into that file:
+          enable_doom_melon=false
+          os="android"
+
+  gn gen out/FooBar --args="enable_doom_melon=true os=\"android\""
+      This will overwrite the build directory with the given arguments.
+      (Note that the quotes inside the args command will usually need to
+      be escaped for your shell to pass through strings values.)
+
+How build arguments are used
+
+  If you want to use an argument, you use declare_args() and specify
+  default values. These default values will apply if none of the steps
+  listed in the "How build arguments are set" section above apply to
+  the given argument, but the defaults will not override any of these.
+
+  Often, the root build config file will declare global arguments that
+  will be passed to all buildfiles. Individual build files can also
+  specify arguments that apply only to those files. It is also useful
+  to specify build args in an "import"-ed file if you want such
+  arguments to apply to multiple buildfiles.
+)";
 
 namespace {