Ninja (which is what does the actual build command execution now) does not support -B. What is your use case? Incremental builds should be reliable enough that -B is not necessary for correctness. I'd suggest touching the relevant files if you want to force them to rebuild, for example: touch $(find . -name "*.java")
On Tue, Sep 25, 2018 at 12:31 AM John Kaye <[email protected]> wrote: > > I'm also a long-time pre-8.0 developer who has added many packages and > heavily customized the framework. How does one unconditionally make (-B) > all targets within a given package using the new build system? > > Thanks, > -John > > > > On Tuesday, December 12, 2017 at 2:08:35 PM UTC-8, Colin Cross wrote: >> >> >> >> On Mon, Dec 11, 2017 at 1:50 PM, Jacob Abrams <[email protected]> wrote: >> >>> Hello, >>> >>> I would like to voice protest over the AOSP build system switch from >>> Make to Soong. Make is not a perfect tool but it is well documented and >>> extremely stable. The introduction of ninja into AOSP was seamless and >>> acceptable. However, migrating away from Make to a totally new tool with >>> zero history is a serious set back. Why not instead choose Bazel, Tup, >>> Gradle, Buck or simply stick with what works? >>> >>> I read the following statements from one of the developers of Soong >>> build: >>> >>> > One of our goals for build health is to reduce the number of different >>> > ways we build modules. Adding too many build flags makes it harder to >>> > tell if a change will break the build, and hard to run tests. We >>> > would much rather compiling everything the same on all devices, and >>> > then determine which parts to use at runtime. >>> >>> It is unclear what is meant by "reduce the number of different ways we >>> build modules.", nor is it clear what is meant by "We would much rather >>> compiling everything the same on all devices". This seems to conflict with >>> the example of LLVM where the build basically consists of completely custom >>> go code: >>> https://android.googlesource.com/platform/external/llvm/+/master/soong/llvm.go >>> >>> Clearly this custom go code does not reduce the number of different ways >>> modules are built. >>> >> >> Some teams have existing flows where they want to locally modify the way >> they build, and we've supported those through the custom go code for those >> modules. In general we still try to avoid them. >> >> >>> I assume this is an attempt to improve build performance yet again, but >>> it ends up wasting thousands of engineering hours across the globe. >>> Engineers must figure out a new system that likely contains numerous bugs >>> and could possibly be destined for the dustbin if it is not maintained >>> properly or turns out to be inferior. If the goal is to improve build >>> performance perhaps Google engineers could explore an under-the-hood >>> contribution to Make itself? >>> >> >> As Glenn pointed out, the purpose for Soong is not primarily performance, >> it is correctness and reliability. Before Soong (and the conversion to >> Ninja was part of Soong), incremental builds were completely unreliable, >> requiring significant knowledge of the internals of the Android build for >> platform developers to get anything done. Wiping the entire output >> directory and rebuilding was common. Incremental builds are now reliable >> enough to be used in our continuous build infrastructure. >> >> Debugging typos in Android.mk files was also very painful. LOCAL_CFALGS >> instead of LOCAL_CFLAGS gets silently ignored, deleting a module that still >> has users doesn't break incremental builds but breaks clean builds, >> overwriting variables that are being used by other modules, subtle >> differences between := and =, or ifdef blah and ifneq(,$(blah)). All of >> these problems are fundamental to the way that Make works and can't be >> fixed. >> >> We've explored various options with Make (for a while we had a modified >> version of Make that would cache its build rules). The conversion to Ninja >> (and all of the speed and reliability improvements that came with it) was >> done by using Kati instead of Make, and we've continued to invest in new >> features there. But most of the improvements have come from moving the >> very complex build code out of the terrible Make language and into a high >> level, maintainable, testable language. >> >> Android is mature; it deserves a mature build system. >>> >>> Jacob Abrams >>> >>> -- >>> -- >>> You received this message because you are subscribed to the "Android >>> Building" mailing list. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/android-building?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Android Building" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> On Mon, Dec 11, 2017 at 1:50 PM, Jacob Abrams <[email protected]> wrote: >> >>> Hello, >>> >>> I would like to voice protest over the AOSP build system switch from >>> Make to Soong. Make is not a perfect tool but it is well documented and >>> extremely stable. The introduction of ninja into AOSP was seamless and >>> acceptable. However, migrating away from Make to a totally new tool with >>> zero history is a serious set back. Why not instead choose Bazel, Tup, >>> Gradle, Buck or simply stick with what works? >>> >>> I read the following statements from one of the developers of Soong >>> build: >>> >>> > One of our goals for build health is to reduce the number of different >>> > ways we build modules. Adding too many build flags makes it harder to >>> > tell if a change will break the build, and hard to run tests. We >>> > would much rather compiling everything the same on all devices, and >>> > then determine which parts to use at runtime. >>> >>> It is unclear what is meant by "reduce the number of different ways we >>> build modules.", nor is it clear what is meant by "We would much rather >>> compiling everything the same on all devices". This seems to conflict with >>> the example of LLVM where the build basically consists of completely custom >>> go code: >>> https://android.googlesource.com/platform/external/llvm/+/master/soong/llvm.go >>> >>> Clearly this custom go code does not reduce the number of different ways >>> modules are built. >>> >>> I assume this is an attempt to improve build performance yet again, but >>> it ends up wasting thousands of engineering hours across the globe. >>> Engineers must figure out a new system that likely contains numerous bugs >>> and could possibly be destined for the dustbin if it is not maintained >>> properly or turns out to be inferior. If the goal is to improve build >>> performance perhaps Google engineers could explore an under-the-hood >>> contribution to Make itself? >>> >>> Android is mature; it deserves a mature build system. >>> >>> Jacob Abrams >>> >>> -- >>> -- >>> You received this message because you are subscribed to the "Android >>> Building" mailing list. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/android-building?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Android Building" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > -- > You received this message because you are subscribed to the "Android > Building" mailing list. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-building?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Android Building" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
