pi@pi-NMH-WCX9:~/workspace/connectedhomeip$ gn help declare_args 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. 将给定的参数引入当前范围。如果未在命令行或工具链的参数中指定它们，则将使用 declare_args 块中给出的默认值。但是，这些默认值不会覆盖命令行值。 See also "gn help buildargs" for an overview. The precise behavior of declare args is: 1. The declare_args() block executes. Any variable defined in the enclosing scope is available for reading, but any variable defined earlier in the current scope is not (since the overrides haven't been applied yet).
2. At the end of executing the block, any variables set within that scope are saved, with the values specified in the block used as the "default value" for that argument. Once saved, these variables are available for override via args.gn.
3. User-defined overrides are applied. Anything setin"gn args" now overrides any default values. The resulting set of variables is promoted to be readable from the following code in the file.
This has some ramifications that may not be obvious:
- You should not perform difficult work inside a declare_args block since this only sets a default value that may be discarded. In particular, don't use the result of exec_script() to set the default value. If you want to have a script-defined default, set some default "undefined" value like [], "", or -1, and after the declare_args block, call exec_script if the value is unset by the user. - Because you cannot read the value of a variable defined in the same block, if you need to make the default value of one arg depend on the possibly-overridden value of another, write two separate declare_args() blocks: declare_args() { enable_foo = true } declare_args() { # Bar defaults to same user-overridden state as foo. enable_bar = enable_foo } Example declare_args() { enable_teleporter = true enable_doom_melon = false } If you want to override the (default disabled) Doom Melon: gn --args="enable_doom_melon=true enable_teleporter=true" This also sets the teleporter, but it's already defaulted to on so it will have no effect.
pi@pi-NMH-WCX9:~/workspace/connectedhomeip$ gn help import 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. import命令会加载给定的文件的规则和变量到当前范围
By convention, imported files are named with a .gni extension. 根据习惯，import文件的有 .gni 后缀
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")
pi@pi-NMH-WCX9:~/workspace/connectedhomeip$ gn help group 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. 此目标类型允许您创建元目标，这些元目标仅将一组依赖项收集到一个命名目标中。组还可以指定适用于其依赖项的配置。