Lines Matching +full:build +full:- +full:other
9 ### Use the built-in help!
11 GN has an extensive built-in help system which provides a reference for
12 every function and built-in variable. This page is more high-level.
25 * Writing build files should not be a creative endeavour. Ideally two
34 * The build language should be opinionated as to how the build should
37 the build simpler rather than making everything more complicated to
48 * 64-bit signed integers.
50 * Lists (of any other types).
51 * Scopes (sort of like a dictionary, only for built-in stuff).
53 There are some built-in variables whose values depend on the current
57 user-defined function calls, for example (templates are the closest thing). As
65 Strings are enclosed in double-quotes and use backslash as the escape
72 Any other use of a backslash is treated as a literal backslash. So, for
79 non-variable-name character to terminate the variable name. More complex
84 b = "$a/foo.cc" # b -> "mypath/foo.cc"
85 c = "foo${a}bar.cc" # c -> "foomypathbar.cc"
88 You can encode 8-bit characters using "$0xFF" syntax, so a string with newlines
95 of thing, you're trying to do too much work in the build.
113 b = a - [ "first" ] # [ "second", "third" ]
114 a -= [ "second" ] # [ "first", "third", "first" ]
117 The - operator on a list searches for matches and removes all matching
123 there is no way to test for inclusion, the main use-case is to set up a
125 the current build based on various conditions.
128 dependency appear once. This is the opposite of the advice Chrome-team used to
132 Lists support zero-based subscripting to extract values:
136 b = a[1] # -> "second"
139 The \[\] operator is read-only and can not be used to mutate the
140 list. The primary use-case of this is when an external script returns
156 Note that execution of the build script is done without intrinsic
168 sources -= [ "something.cc" ]
182 the build should do can normally be expressed without doing this, and if you
194 Simple function calls look like most other languages:
201 Such functions are built-in and the user can not define new ones.
215 function for the function to execute. Most of the block-style functions execute
225 There is no way to modify any enclosing scope other than the innermost
237 the current build file's directory. There are three possible forms:
247 Source-tree absolute names:
261 ## Build configuration
265 A target is a node in the build graph. It usually represents some kind
267 other targets. The built-in target types (see `gn help <targettype>` for
275 * `group`: A virtual dependency node that refers to one or more other
280 preferrable over a real static library since it will build faster).
285 Chrome some of the more commonly-used templates are:
288 build type.
292 * `android_apk`: Make an APK. There are a _lot_ of other Android ones, see
293 `//build/config/android/rules.gni`.
318 It is common for the build config file to specify target defaults that
328 A target can apply settings to other targets that depend on it. The most
367 discouraged as it can spray flags and defines over more of the build than
370 In Chrome, prefer the build flag header system (`build/buildflag_header.gni`)
371 for defines which prevents most screw-ups with compiler defines.
375 Templates are GN's primary way to re-use code. Typically, a template
376 would expand to one or more other target types.
390 # When other targets depend on your template invocation, this will be the
424 invoking build file rather than the template source file. This is so
433 ## Other features
443 multiply-included files.
445 Typically, a `.gni` would define build arguments and templates. See `gn
455 scripts, which are executed with the build output directory as the
456 current directory, while build files usually refer to files relative to
461 name relative to the current directory to be relative to the root build
477 Python. The first way is as a build step. Such a script would take some
478 input and generate some output as part of the build. Targets that invoke
482 The second way to execute scripts is synchronously during build file
484 to compile, or to get certain system configurations that the build file
485 might depend on. The build file can read the stdout of the script and
499 occasionally necessary when synchronously running scripts. The typical use-case
500 would be to pass a list of file names longer than the command-line limits of
504 Actions that exceed command-line length limits can use response files to
510 Blaze is Google's internal build system, now publicly released as
511 [Bazel](http://bazel.io/). It has inspired a number of other systems such as
523 in GN is a result of trying to separate this concept out into the build
528 GYP code easier, and the GYP constructs generally offer more fine-grained