Lines Matching refs:be

16 by `m` would cause `mymodule` to be presinstalled on the device, even if it wasn't listed in
20 did a clean build. This behavior can be disabled by setting the
24 module system will not be compatible with this change. This includes many usages of
38 space-separated list of plugins to omit from the validation. This must be set
46 scripts run directly from makefiles, or from soong genrules. This behavior can be
51 In addition, `python_*` soong modules no longer allow python 2. This can be temporarily
71 from a module named `bar` can be done like so:
133 `BUILD_BROKEN_DEPFILE` can be used to allowlist usage of depfile in `gensrcs`.
168 `BUILD_BROKEN_INPUT_DIR_MODULES` can be used to allowlist specific directories
176 access to the manifest contents, that information must be present in the build
186 If a library is in `libs`, it usually should *not* be added to the above
187 properties, and Soong should be able to infer the `<uses-library>` tag. But
193 `<uses-library>` with a given name (however, this is discouraged and will be
229 System properties for each of the partition is supposed to be set via following
235 * `PRODUCT_SYSTEM_DEFAULT_PROPERTIES` is highly discouraged. Will be deprecated.
240 * `PRODUCT_PROPERTY_OVERRIDES` is highly discouraged. Will be deprecated.
241 * `PRODUCT_DEFAULT_PROPERTY_OVERRIDES` is also discouraged. Will be deprecated.
284 System properties can now be set as optional using the new syntax:
299 Optional assignments can be duplicated and in that case their order matters.
327 We've considered `BUILD_COPY_HEADERS`/`LOCAL_COPY_HEADERS` to be deprecated for
328 a long time, and the places where it's been able to be used have shrinked over
351 With `ALLOW_NINJA_ENV=false` (soon to be the default), ninja, and all the
365 to allow specific variables to be passed through until you've fixed the rules.
369 Include directories are expected to be within the source tree (or in the output
414 under recovery. Android Q has added such support (HALs will be loaded in
436 in Android.mk) would cause both to be built and installed. In many cases you
437 only want either the host or target versions to be built/installed by default,
438 and would be over-building with both. So `PRODUCT_PACKAGES` will be changing to
447 * `PRODUCT_HOST_PACKAGES` requires listed modules to exist, and be host
454 necessary in `PRODUCT_*PACKAGES`, and tended to be over-built (especially the
464 In Android.mk files, you used to be able to change LOCAL_ARM_MODE for each
469 files to be split out into a separate static library that chooses `arm` over
470 `thumb` for the entire library. This must now also be done in Android.mk files.
474 Modules that build for Windows (our only `HOST_CROSS` OS currently) must now be
480 modules to specify that they should always be installed on `-eng`, or `-eng`
482 specify which modules should be installed, effectively making it impossible to
494 `USER` will soon be `nobody` in many cases due to the addition of a sandbox
499 Similarly, the `hostname` tool will also be returning a more consistent value
504 `BUILD_NUMBER` should not be used directly in Android.mk files, as it would
505 trigger them to be re-read every time the `BUILD_NUMBER` changes (which it does
524 specified, and the goal would be built (either explicitly on the command line,
525 or as a dependency of something on the command line), that file will be copied
554 Instead of specifying just a file, a destination name can be specified,
570 for real files to be built, but any target marked with `.PHONY` is also always
571 considered dirty, needing to be rebuilt every build. This isn't a problem for
573 on a `.PHONY` target, it can get quite expensive for what should be a tiny
591 1. The target isn't intended to be a real file, and should be marked with
592    `.PHONY`. This would be the case for this example.
594    outputs from the build system should be within the output directory,
602 If the first target isn't intended to be a real file, then it should be marked
606 If the second (PHONY) target is a real file, it may unnecessarily be marked
635 relatively smaller builds (like the kernel), this may be reasonable as long as
643 Device specific configuration should not be able to affect common core build
644 steps -- we're looking at triggering build steps to be invalidated if the set
648 be.
657 future, others will be cleared. (There will be methods to get custom variables
718 If this causes multiple modules to be named the same, use unique module names
735 Can be rewritten as:
791 to be used (with logging). Beware that GCC didn't work well with the interposer
822 All of the make variables may be relative paths from the current directory, or
835 root of the source tree, so this can just be replaced with '.' (which is what
848 already be adding that as a dependency).
850 Depending on the rule, passing the file path itself may not be feasible due to
851 layers of unchangable scripts/binaries. In that case, be sure to add the
901 `BUILD_BROKEN_CLANG_PROPERTY` can be used as temporarily workaround
921 `BUILD_BROKEN_CLANG_ASFLAGS` and `BUILD_BROKEN_CLANG_CFLAGS` can be used as temporarily workarounds
937 ### Soong config string variables must list all values they can be set to
940 must only be set to a value listed in their `values` property, or an empty string.
966 $(call soong_config_set,my_namespace,my_string_variable,baz) # Will be an error as baz is not liste…