Lines Matching refs:build

7 soong_ui has tracing built in, so that every build execution's trace can be
8 viewed.  Just open `$OUT_DIR/build.trace.gz` in Chrome's <chrome://tracing>, or
10 stored in `build.trace.#.gz` (larger numbers are older). The associated logs
24 …0:00 build out/target/product/generic_arm64/obj/FAKE/sepolicy_neverallows_intermediates/policy_2.c…
25 …0:04 build out/target/product/generic_arm64/obj/FAKE/sepolicy_neverallows_intermediates/sepolicy_n…
26 …0:13 build out/target/product/generic_arm64/obj/ETC/plat_sepolicy.cil_intermediates/plat_sepolicy.…
27 …0:01 build out/target/product/generic_arm64/obj/ETC/plat_pub_versioned.cil_intermediates/plat_pub_…
28 …0:02 build out/target/product/generic_arm64/obj/ETC/vendor_sepolicy.cil_intermediates/vendor_sepol…
29     0:16 build out/target/product/generic_arm64/obj/ETC/sepolicy_intermediates/sepolicy
30 …0:00 build out/target/product/generic_arm64/obj/ETC/plat_seapp_contexts_intermediates/plat_seapp_c…
32     0:02 build out/target/product/generic_arm64/obj/NOTICE.txt
33     0:00 build out/target/product/generic_arm64/obj/NOTICE.xml.gz
34     0:00 build out/target/product/generic_arm64/system/etc/NOTICE.xml.gz
45 parallelism on the build machine will improve total build times.  If there are
46 long individual times listed in the critical path then improving build times
48 in the build graph will improve total build times.
54 don't currently have an easy way to enable them in the context of a full build.
59 performance sensitive, since it doesn't need to happen on every build. It is
63 or read a file that's going to change on every build.
78 verbose: *kati*:   0.010 / 1 git -C test/framework/build log -s -n 1 --format="%cd" --date=format:"…
148 read with the `ckati_stamp_dump` tool in prebuilts/build-tools. More debugging
160 verbose: *kati*:  13.137 / 20144 build/make/core/soong_cc_prebuilt.mk
161 verbose: *kati*:  11.743 / 27666 build/make/core/base_rules.mk
163 verbose: *kati*:   2.054 /     1 art/build/Android.cpplint.mk
164 verbose: *kati*:   1.955 / 28269 build/make/core/clear_vars.mk
165 verbose: *kati*:   1.795 /   283 build/make/core/package.mk
166 verbose: *kati*:   1.790 /   283 build/make/core/package_internal.mk
167 verbose: *kati*:   1.757 / 17382 build/make/core/link_type.mk
168 verbose: *kati*:   1.078 /   297 build/make/core/aapt2.mk
182 $(KATI_profile_makefile build/make/core/product.mk)
196 Add `NINJA_ARGS="-d explain"` to your environment before a build, this will cause
220 You'll likely need to cross-reference this data against the build graph in the
226 If the long part in the trace view of a build is a relatively solid block, then
227 the performance is probably more related to how much time the actual build
234 for build commands to impact unrelated build commands. This is an area we'd
247 does slow down builds, as we need to verify/produce/load a larger build graph.
249 As of Android Q, loading large build graphs is fast, and in Android R, `mm` is
255 every incremental build, even if there was nothing to do. This was fixed in
258 they appear to cause ninja to spend more time during every build loading the
261 A workaround to get out of this state is to remove the build.ninja entry from
265 sed -i "/\/build.ninja/d" $(get_build_var OUT_DIR)/.ninja_log