Lines Matching refs:be
7 in Android.mk) would cause both to be built and installed. In many cases you
8 only want either the host or target versions to be built/installed by default,
9 and would be over-building with both. So `PRODUCT_PACKAGES` will be changing to
18 * `PRODUCT_HOST_PACKAGES` requires listed modules to exist, and be host
25 necessary in `PRODUCT_*PACKAGES`, and tended to be over-built (especially the
35 In Android.mk files, you used to be able to change LOCAL_ARM_MODE for each
40 files to be split out into a separate static library that chooses `arm` over
41 `thumb` for the entire library. This must now also be done in Android.mk files.
45 Modules that build for Windows (our only `HOST_CROSS` OS currently) must now be
51 modules to specify that they should always be installed on `-eng`, or `-eng`
53 specify which modules should be installed, effectively making it impossible to
65 `USER` will soon be `nobody` in many cases due to the addition of a sandbox
70 Similarly, the `hostname` tool will also be returning a more consistent value
75 `BUILD_NUMBER` should not be used directly in Android.mk files, as it would
76 trigger them to be re-read every time the `BUILD_NUMBER` changes (which it does
95 specified, and the goal would be built (either explicitly on the command line,
96 or as a dependency of something on the command line), that file will be copied
107 Instead of specifying just a file, a destination name can be specified,
123 for real files to be built, but any target marked with `.PHONY` is also always
124 considered dirty, needing to be rebuilt every build. This isn't a problem for
126 on a `.PHONY` target, it can get quite expensive for what should be a tiny
144 1. The target isn't intended to be a real file, and should be marked with
145 `.PHONY`. This would be the case for this example.
147 outputs from the build system should be within the output directory,
155 If the first target isn't intended to be a real file, then it should be marked
159 If the second (PHONY) target is a real file, it may unnecessarily be marked
188 relatively smaller builds (like the kernel), this may be reasonable as long as
197 reading: these will throw a warnings, and will be an error in the future.
198 Device specific configuration should not be able to affect common core build
199 steps -- we're looking at triggering build steps to be invalidated if the set
203 be.
213 future, others will be cleared. (There will be methods to get custom variables
274 If this causes multiple modules to be named the same, use unique module names
291 Can be rewritten as:
347 to be used (with logging). Beware that GCC didn't work well with the interposer
378 All of the make variables may be relative paths from the current directory, or
391 root of the source tree, so this can just be replaced with '.' (which is what
404 already be adding that as a dependency).
406 Depending on the rule, passing the file path itself may not be feasible due to
407 layers of unchangable scripts/binaries. In that case, be sure to add the