Colin, are you meaning that incremental builds are fine starting from Oreo or P? I don't have a deep knowledge of all AOSP build structure, but I was thinking that in order to fix incremental build issues al the Makefile shall be converted to Blueprint files...at the moment only a subset of makefiles have been migrated, do you think that, at a certain point in time, all the Makefile will be substituted by Blueprint?
Just out of curiosity have you ever analysed a migration to Yocto build system? For sure it is not a trivial move, but Yocto has already solved lot of issues that are common to AOSP build system and it is for sure a very modular build system... BR, Alessio Il giorno martedì 12 dicembre 2017 23:08:35 UTC+1, Colin Cross ha scritto: > > > > 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] >> <javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > On Mon, Dec 11, 2017 at 1:50 PM, Jacob Abrams <[email protected] > <javascript:>> 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] >> <javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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] <javascript:>. >> 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.
