Cleaning should be unnecessary. Just do incremental builds.
On Mon, Oct 1, 2018 at 1:18 PM John Kaye <[email protected]> wrote: > > If I'm integrating a large package (Samba, for example), I go through many > clean and (re)build cycles until I get a working result. I would typically > use (-B) for that. Is there a ninja way to clean a specific package/target > rather than the entire build? Thanks, -John > > On Tuesday, September 25, 2018 at 10:35:08 AM UTC-7, Colin Cross wrote: >> >> 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. > -- -- 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.
