GN Reference

Posted 2021-09-13 知识店铺

GN Reference

This page is automatically generated from gn help --markdown all.

--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\\"]"

--[no]color: Forces colored output on or off.

  Normally GN will try to detect whether it is outputting to a terminal
  and will enable or disable color accordingly. Use of these switches
  will override the default.

Examples

  gn gen out/Default --color

  gn gen out/Default --nocolor

--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.

--markdown: write the output in the Markdown format.

--[no]color: Forces colored output on or off.

  Normally GN will try to detect whether it is outputting to a terminal
  and will enable or disable color accordingly. Use of these switches
  will override the default.

Examples

  gn gen out/Default --color

  gn gen out/Default --nocolor

-q: Quiet mode. Don\'t print output on success.

  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.

  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"

--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").

--time: Outputs a summary of how long everything took.

  Hopefully self-explanatory.

Examples

  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.

  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

-v: Verbose logging.

  This will spew logging events to the console for debugging issues.
  Good luck!

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).

gn check <out_dir> [<label_pattern>] [--force]

  "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 .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".

Command-specific switches

  --force
      Ignores specifications of "check_includes = false" and checks
      all target\'s files that match the target label.

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.

gn clean <out_dir>

  Deletes the contents of the output directory except for args.gn and
  creates a Ninja build environment sufficient to regenerate the build.

gn desc <out_dir> [] [--blame]

  Displays information about a given labeled target for the given build.
  The build parameters will be taken for the build in the given
  <out_dir>.

Possibilities for

  (If unspecified an overall summary will be displayed.)

  sources
      Source files.

  inputs
      Additional input dependencies.

  public
      Public header files.

  check_includes
      Whether "gn check" checks this target for include usage.

  allow_circular_includes_from
      Permit includes from these targets.

  visibility
      Prints which targets can depend on this one.

  testonly
      Whether this target may only be used in tests.

  configs
      Shows configs applied to the given target, sorted in the order
      they\'re specified. This includes both configs specified in the
      "configs" variable, as well as configs pushed onto this target
      via dependencies specifying "all" or "direct" dependent
      configs.

  deps
      Show immediate or recursive dependencies. See below for flags that
      control deps printing.

  public_configs
  all_dependent_configs
      Shows the labels of configs applied to targets that depend on this
      one (either directly or all of them).

  forward_dependent_configs_from
      Shows the labels of dependencies for which dependent configs will
      be pushed to targets depending on the current one.

  script
  args
  depfile
      Actions only. The script and related values.

  outputs
      Outputs for script and copy target types.

  defines       [--blame]
  include_dirs  [--blame]
  cflags        [--blame]
  cflags_cc     [--blame]
  cflags_cxx    [--blame]
  ldflags       [--blame]
  lib_dirs
  libs
      Shows the given values taken from the target and all configs
      applying. See "--blame" below.

  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

  --blame
      Used with any value specified by a config, this will name
      the config that specified the value. 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).

Flags that control how deps are printed

  --all
      Collects all recursive dependencies and prints a sorted flat list.
      Also usable with --tree (see below).

  --as=(buildfile|label|output)
      How to print targets.

      buildfile
          Prints the build files where the given target was declared as
          file names.
      label  (default)
          Prints the label of the target.
      output
          Prints the first output file for the target relative to the
          current directory.

  --testonly=(true|false)
      Restrict outputs to targets with the testonly flag set
      accordingly. When unspecified, the target\'s testonly flags are
      ignored.

  --tree
      Print a dependency tree. By default, duplicates will be elided
      with "..." but when --all and -tree are used together, no
      eliding will be performed.

      The "deps", "public_deps", and "data_deps" will all be
      included in the tree.

      Tree output can not be used with the filtering or output flags:
      --as, --type, --testonly.

  --type=(action|copy|executable|group|shared_library|source_set|
          static_library)
      Restrict outputs to targets matching the given type. If
      unspecified, no filtering will be performed.

Note

  This command will show the full name of directories and source files,
  but when directories and source paths are written to the build file,
  they will be adjusted to be relative to the build directory. So the
  values for paths displayed by this command won\'t match (but should
  mean the same thing).

Examples

  gn desc out/Debug //base:base
      Summarizes the given target.

  gn desc out/Foo :base_unittests deps --tree
      Shows a dependency tree of the "base_unittests" project in
      the current directory.

  gn desc out/Debug //base defines --blame
      Shows defines set for the //base:base target, annotated by where
      each one was set from.

gn format [--dump-tree] [--in-place] [--stdin] BUILD.gn

  Formats .gn file to a standard format.

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 only, dumps the parse tree.

  --in-place
      Instead of writing the formatted file to stdout, replace the input
      file with the formatted output. If no reformatting is required,
      the input file will not be touched, and nothing printed.

  --stdin
      Read input from stdin (and write to stdout). Not compatible with
      --in-place of course.

Examples

  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 <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" for the common command-line switches.

gn help

  Yo dawg, I heard you like help on your help so I put help on the help
  in the help.

gn ls <out_dir> [<label_pattern>] [--all-toolchains] [--as=...]

      [--type=...] [--testonly=...]

  Lists all targets matching the given pattern for the given build
  directory. By default, only targets in the default toolchain will
  be matched unless a toolchain is explicitly supplied.

  If the label pattern is unspecified, list all targets. The label
  pattern is not a general regular expression (see
  "gn help label_pattern"). If you need more complex expressions,
  pipe the result through grep.

Options

  --as=(buildfile|label|output)
      How to print targets.

      buildfile
          Prints the build files where the given target was declared as
          file names.
      label  (default)
          Prints the label of the target.
      output
          Prints the first output file for the target relative to the
          current directory.

  --all-toolchains
      Matches all toolchains. When set, if the label pattern does not
      specify an explicit toolchain, labels from all toolchains will be
      matched. When unset, only targets in the default toolchain will
      be matched unless an explicit toolchain in the label is set.

  --testonly=(true|false)
      Restrict outputs to targets with the testonly flag set
      accordingly. When unspecified, the target\'s testonly flags are
      ignored.

  --type=(action|copy|executable|group|shared_library|source_set|
          static_library)
      Restrict outputs to targets matching the given type. If
      unspecified, no filtering will be performed.

Examples

  gn ls out/Debug
      Lists all targets in the default toolchain.

  gn ls out/Debug "//base/*"
      Lists all targets in the directory base and all subdirectories.

  gn ls out/Debug "//base:*"
      Lists all targets defined in //base/BUILD.gn.

  gn ls out/Debug //base --as=output
      Lists the build output file for //base:base

  gn ls out/Debug --type=executable
      Lists all executables produced by the build.

  gn ls out/Debug "//base/*" --as=output | xargs ninja -C out/Debug
      Builds all targets in //base and all subdirectories.

  gn ls out/Debug //base --all-toolchains
      Lists all variants of the target //base:base (it may be referenced
      in multiple toolchains).

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.

  Each dependency will be annotated with its type. By default, only the
  first path encountered will be printed, which is not necessarily the
  shortest path.

Options

  --all
     Prints all paths found rather than just the first one.

Example

  gn path out/Default //base //tools/gn

gn refs <out_dir> (<label_pattern>|||@<response_file>)* [--all]

        [--all-toolchains] [--as=...] [--testonly=...] [--type=...]

  Finds reverse dependencies (which targets reference something). The
  input is a list containing:

   - Target label: The result will be which targets depend on it.

   - Config label: The result will be which targets list the given
     config in its "configs" or "public_configs" list.

   - Label pattern: The result will be which targets depend on any
     target matching the given pattern. Patterns will not match
     configs. These are not general regular expressions, see
     "gn help label_pattern" for details.

   - File name: The result will be which targets list the given file in
     its "inputs", "sources", "public", "data", or "outputs".
     Any input that does not contain wildcards and does not match a
     target or a config will be treated as a file.

   - Response file: If the input starts with an "@", it will be
     interpreted as a path to a file containing a list of labels or
     file names, one per line. This allows us to handle long lists
     of inputs without worrying about command line limits.

Options

  --all
      When used without --tree, will recurse and display all unique
      dependencies of the given targets. For example, if the input is
      a target, this will output all targets that depend directly or
      indirectly on the input. If the input is a file, this will output
      all targets that depend directly or indirectly on that file.

      When used with --tree, turns off eliding to show a complete tree.

  --all-toolchains
      Normally only inputs in the default toolchain will be included.
      This switch will turn on matching all toolchains.

      For example, a file is in a target might be compiled twice:
      once in the default toolchain and once in a secondary one. Without
      this flag, only the default toolchain one will be matched and
      printed (potentially with its recursive dependencies, depending on
      the other options). With this flag, both will be printed
      (potentially with both of their recursive dependencies).

  --as=(buildfile|label|output)
      How to print targets.

      buildfile
          Prints the build files where the given target was declared as
          file names.
      label  (default)
          Prints the label of the target.
      output
          Prints the first output file for the target relative to the
          current directory.

  -q
     Quiet. If nothing matches, don\'t print any output. Without this
     option, if there are no matches there will be an informational
     message printed which might interfere with scripts processing the
     output.

  --testonly=(true|false)
      Restrict outputs to targets with the testonly flag set
      accordingly. When unspecified, the target\'s testonly flags are
      ignored.

  --tree
      Outputs a reverse dependency tree from the given target.
      Duplicates will be elided. Combine with --all to see a full
      dependency tree.

      Tree output can not be used with the filtering or output flags:
      --as, --type, --testonly.

  --type=(action|copy|executable|group|shared_library|source_set|
          static_library)
      Restrict outputs to targets matching the given type. If
      unspecified, no filtering will be performed.

Examples (target input)

  gn refs out/Debug //tools/gn:gn
      Find all targets depending on the given exact target name.

  gn refs out/Debug //base:i18n --as=buildfiles | xargs gvim
      Edit all .gn files containing references to //base:i18n

  gn refs out/Debug //base --all
      List all targets depending directly or indirectly on //base:base.

  gn refs out/Debug "//base/*"
      List all targets depending directly on any target in //base or
      its subdirectories.

  gn refs out/Debug "//base:*"
      List all targets depending directly on any target in
      //base/BUILD.gn.

  gn refs out/Debug //base --tree
      Print a reverse dependency tree of //base:base

Examples (file input)

  gn refs out/Debug //base/macros.h
      Print target(s) listing //base/macros.h as a source.

  gn refs out/Debug //base/macros.h --tree
      Display a reverse dependency tree to get to the given file. This
      will show how dependencies will reference that file.

  gn refs out/Debug //base/macros.h //base/at_exit.h --all
      Display all unique targets with some dependency path to a target
      containing either of the given files as a source.

  gn refs out/Debug //base/macros.h --testonly=true --type=executable
          --all --as=output
      Display the executable file names of all test executables
      potentially affected by a change to the given file.

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
  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".

  It is recommended you put inputs to your script in the "sources"
  variable, and stuff like other Python files required to run your
  script in the "inputs" variable.

  The "deps" and "public_deps" for an action will always be
  completed before any part of the action is run so it can depend on
  the output of previous steps. The "data_deps" will be built if the
  action is built, but may not have completed before all steps of the
  action are started. This can give additional parallelism in the build
  for runtime-only dependencies.

Outputs

  You should specify files created by your script by specifying them in
  the "outputs".

  The script will be executed with the given arguments with the current
  directory being that of the root build directory. If you pass files
  to your script, see "gn help rebase_path" for how to convert
  file names to be relative to the build directory (file names in the
  sources, outputs, and inputs will be all treated as relative to the
  current build file and converted as needed automatically).

File name handling

  All output files must be inside the output directory of the build.
  You would generally use |$target_out_dir| or |$target_gen_dir| to
  reference the output or generated intermediate file directories,
  respectively.

Variables

  args, data, data_deps, depfile, deps, outputs*, script*,
  inputs, 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)
  }

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.

  You can dynamically write input dependencies (for incremental rebuilds
  if an input file changes) by writing a depfile when the script is run
  (see "gn help depfile"). This is more flexible than "inputs".

  The "deps" and "public_deps" for an action will always be
  completed before any part of the action is run so it can depend on
  the output of previous steps. The "data_deps" will be built if the
  action is built, but may not have completed before all steps of the
  action are started. This can give additional parallelism in the build
  for runtime-only dependencies.

Outputs

  The script will be executed with the given arguments with the current
  directory being that of the root build directory. If you pass files
  to your script, see "gn help rebase_path" for how to convert
  file names to be relative to the build directory (file names in the
  sources, outputs, and inputs will be all treated as relative to the
  current build file and converted as needed automatically).

File name handling

  All output files must be inside the output directory of the build.
  You would generally use |$target_out_dir| or |$target_gen_dir| to
  reference the output or generated intermediate file directories,
  respectively.

Variables

  args, data, data_deps, depfile, deps, outputs*, script*,
  inputs, 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" ]
  }

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")

config: Defines a configuration object.

  Configuration objects can be applied to targets and specify sets of
  compiler flags, includes, defines, etc. They provide a way to
  conveniently group sets of this configuration information.

  A config is referenced by its label just like a target.

  The values in a config are additive only. If you want to remove a flag
  you need to remove the corresponding config that sets it. The final
  set of flags, defines, etc. for a target is generated in this order:

   1. The values specified directly on the target (rather than using a
      config.
   2. The configs specified in the target\'s "configs" list, in order.
   3. Public_configs from a breadth-first traversal of the dependency
      tree in the order that the targets appear in "deps".
   4. All dependent configs from a breadth-first traversal of the
      dependency tree in the order that the targets appear in "deps".

Variables valid in a config definition:

  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
         defines, include_dirs, ldflags, lib_dirs, libs
         precompiled_header, precompiled_source

Variables on a target used to apply configs:

  all_dependent_configs, configs, public_configs,
  forward_dependent_configs_from

Example:

  config("myconfig") {
    includes = [ "include/common" ]
    defines = [ "ENABLE_DOOM_MELON" ]
  }

  executable("mything") {
    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.

  Both "sources" and "outputs" must be specified. Sources can
  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 files to output file names using source
  expansion (see "gn help source_expansion"). The placeholders will
  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}}" ]
  }

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.

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.

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"
    }
  }

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")

executable: Declare an executable target.

Variables

  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
         defines, include_dirs, ldflags, lib_dirs, libs
         precompiled_header, precompiled_source
  Deps: data_deps, deps, forward_dependent_configs_from, public_deps
  Dependent configs: all_dependent_configs, public_configs
  General: check_includes, configs, data, inputs, output_name,
           output_extension, public, sources, testonly, visibility

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 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

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_gen_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".

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 currebt 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")

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")
  }

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")

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. Direct dependent configs will get automatically
  forwarded through the group so you shouldn\'t need to use
  "forward_dependent_configs_from.

Variables

  Deps: data_deps, deps, forward_dependent_configs_from, public_deps
  Dependent configs: all_dependent_configs, public_configs

Example

  group("all") {
    deps = [
      "//project:runner",
      "//project:unit_tests",
    ]
  }

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")

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)

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" ]

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")

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.

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)
  }

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.

  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")

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.

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"
  }

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 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.

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" instead.

Variables

  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
         defines, include_dirs, ldflags, lib_dirs, libs
         precompiled_header, precompiled_source
  Deps: data_deps, deps, forward_dependent_configs_from, public_deps
  Dependent configs: all_dependent_configs, public_configs
  General: check_includes, configs, data, inputs, output_name,
           output_extension, public, sources, testonly, visibility

source_set: Declare a source set target.

  A source set is a collection of sources that get compiled, but are not
  linked to produce any kind of library. Instead, the resulting object
  files are implicitly added to the linker line of all targets that
  depend on the source set.

  In most cases, a source set will behave like a static library, except
  no actual library file will be produced. This will make the build go
  a little faster by skipping creation of a large static library, while
  maintaining the organizational benefits of focused build targets.

  The main difference between a source set and a static library is
  around handling of exported symbols. Most linkers assume declaring
  a function exported means exported from the static library. The linker
  can then do dead code elimination to delete code not reachable from
  exported functions.

  A source set will not do this code elimination since there is no link
  step. This allows you to link many sources sets into a shared library
  and have the "exported symbol" notation indicate "export from the
  final shared library and not from the intermediate targets." There is
  no way to express this concept when linking multiple static libraries
  into a shared library.

Variables

  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
         defines, include_dirs, ldflags, lib_dirs, libs
         precompiled_header, precompiled_source
  Deps: data_deps, deps, forward_dependent_configs_from, public_deps
  Dependent configs: all_dependent_configs, public_configs
  General: check_includes, configs, data, inputs, output_name,
           output_extension, public, sources, testonly, visibility

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

  Flags: cflags, cflags_c, cflags_cc, cflags_objc, cflags_objcc,
         defines, include_dirs, ldflags, lib_dirs, libs
         precompiled_header, precompiled_source
  Deps: data_deps, deps, forward_dependent_configs_from, public_deps
  Dependent configs: all_dependent_configs, public_configs
  General: check_includes, configs, data, inputs, output_name,
           output_extension, public, sources, testonly, visibility

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.

More details:

  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. Thi
以上是关于GN Reference的主要内容，如果未能解决你的问题，请参考以下文章
 
 如何使用 Android 片段？
 滑动时 ViewPager 更新片段
 如何在 gn 中包含共享库
 跨平台：GN实践详解（ninja, 编译, windows/mac/android实战）
 WebRTC Native M96版本开篇之旅--一篇读懂代码下载编译(ninja gn depot_tools)
 WebRTC Native M96版本开篇之旅--一篇读懂代码下载编译(ninja gn depot_tools)