| commit | 9767223dc547f894ce6fd52da0b9186e225057f0 | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Wed May 27 00:09:16 2020 -0700 |
| committer | Dan Willemsen <dwillemsen@google.com> | Wed May 27 19:37:03 2020 -0700 |
| tree | a48cd0c29123d623232dab6aa2fe68ce029f76e5 | |
| parent | a29edba6e86cde74fa48851f8faa943c1cff2b3b [diff] |
Fix up recovery_text_res
First, make it safer for incremental builds. We used to just be
depending on the bootable/recovery/tools/recovery_l10n/res dir as a
dependency, but that would only trigger a rebuild if a direct child
file/directory was added or removed (so essentially, when a translation
was addded or removed). If a translation was updated, it wouldn't
re-trigger recovery_text_res.
So instead of depending on the directory, depend on the results from
running `find` to list all of the contents in that directory.
Next, move it out of PACKAGING. `m installclean`, which runs in between
incremental builds on our build servers, deletes the obj/PACKAGING
directory. So when recovery_text_res used that directory, we were having
to rebuild it on every incremental build, which isn't optimal when it
takes nearly 90s to build.
So with:
$ lunch aosp_coral-eng
$ m bootimage
$ m installclean
$ m bootimage
The second `m bootimage` went from executing 666 actions in 93s to
executing 658 actions in 6s.
Finally, remove the last uses of $(call include-path-for,recovery),
since they were all in this file (and they weren't using it for include
paths...). We'd like to remove all of these and switch them to header
libraries or other use cases, but in this case, it's just shorter to use
the real path.
Test: treehugger
Test: m bootimage;
touch bootable/recovery/tools/recovery_l10n/res/values/strings.xml
m bootimage
Test: m bootimage; m installclean; m bootimage
Change-Id: I005592e49443aab45ed039a2f0c63f7a69035565
This is the Makefile-based portion of the Android Build System.
For documentation on how to run a build, see Usage.txt
For a list of behavioral changes useful for Android.mk writers see Changes.md
For an outdated reference on Android.mk files, see build-system.html. Our Android.mk files look similar, but are entirely different from the Android.mk files used by the NDK build system. When searching for documentation elsewhere, ensure that it is for the platform build system -- most are not.
This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.