Lines Matching +full:build +full:- +full:no +full:- +full:tests

7 ### Location of build files
9 It usually makes sense to have more build files closer to the code than
17   * Most BUILD files should have a target with the same name as the
19   * Other targets should be in some logical order -- usually
20     more important targets will be first, and unit tests will follow the
21     corresponding target. If there's no clear ordering, consider
25     include as public deps the non-test-support version of the library
26     so tests need only depend on the test\_support target (rather than
34     Prefer to give such targets short, non-redundant names without worrying
39     output names. Give such targets short non-unique names above, and then
41   * Executables and tests should be given a globally unique name. Technically
55 Example for the `src/foo/BUILD.gn` file:
59 # Use of this source code is governed by a BSD-style license that can be
101 GN contains a built-in code formatter which defines the formatting style.
133   * Other deps should always use fully-qualified path names unless
136     names](reference.md#implicit-names).
149 Use fully-qualified paths for imports:
166 be brought into the build. Source sets result in every object file being added
171     object files with no symbols referenced from within the shared library will
177   * Unit tests (and anything else with static initializers with side effects)
179     that register the test. But since no code references symbols in the object
181     means the tests will get stripped.
188     between source sets and static libraries depending on the build
193   * Source sets can have no sources, while static libraries will give strange
194     platform-specific errors if they have no sources. If a target has only
195     headers (for include checking purposes) or conditionally has no sources on
207 A component is a Chrome template (rather than a built-in GN concept) that
214 Much like the source set versus static library tradeoff, there's no hard
231 (non-linked) dependency on a shared library.
236 Use loadable modules for things like plugins. In the case of plugin-like
242 ## Build arguments
246 Build arguments should be scoped to a unit of behavior, e.g. enabling a feature.
248 the subset of the build that could make use of it.
250 Chrome has many legacy flags in `//build/config/features.gni`,
251 `//build/config/ui.gni`. These locations are deprecated. Feature flags should
252 go along with the code for the feature. Many browser-level features can go
253 somewhere in `//chrome/` without lower-level code knowing about it. Some
256 components and have build files in chrome or content import it if necessary.
258 The way to think about things in the `//build` directory is that this is
259 DEPSed into various projects like V8 and WebRTC. Build flags specific to
260 code outside of the build directory shouldn't be in the build directory, and
264 `//build/buildflag_header.gni` which allows preprocessor defines to be
280 While there are no hard and fast rules around argument naming there are
283 `gn args out/Debug --list --short`.
285 `use_foo` - indicates dependencies or major codepaths to include (e.g.
288 `enable_foo` - indicates feature or tools to be enabled (e.g.
291 `disable_foo` - _NOT_ recommended, use `enable_foo` instead with swapped default
294 `is_foo` - usually a global state descriptor (e.g. `is_chrome_branded`,
295 `is_desktop_linux`); poor choice for non-globals
297 `foo_use_bar` - prefixes can be used to indicate a limited scope for an argument
302 Prefix top-level local variables within `.gni` files with an underscore. This