Soong confusion

[Jeffrey Blattman]

I'm wondering if there's a guide, or something that describes the 8.0 build setup ... targeted at someone coming from a pre-8.0 source base. The Soong FAQ here: 

https://android.googlesource.com/platform/build/soong/

has ONE question.

As a side note ... if you are interested in making it easier for vendors to get running with and upgrade their Android dists faster, introducing a new, proprietary build system does not further that end.

[Glenn Kasten]

Thank you for feedback and request for improving the documentation.

As I understand, the primary goals of the new build system were:

 - reliable incremental builds

 - module definitions less error-prone

 - build output more predictable across devices

Obviously these goals may result in an initial learning curve for porting,

but hopefully we can improve the documentation to overcome that hurdle. 

[Jacob Abrams]

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

[Colin Cross]

On Mon, Dec 11, 2017 at 1:50 PM, Jacob Abrams <satur...@gmail.com> 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 android-building@googlegroups.com
To unsubscribe from this group, send email to
android-building+unsubscribe@googlegroups.com
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 android-building+unsubscribe@googlegroups.com.
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 android-building@googlegroups.com
To unsubscribe from this group, send email to
android-building+unsubscribe@googlegroups.com
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 android-building+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Kaye]

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 <satur...@gmail.com> 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 android-...@googlegroups.com

To unsubscribe from this group, send email to

android-buildi...@googlegroups.com

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 android-buildi...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On Mon, Dec 11, 2017 at 1:50 PM, Jacob Abrams <satur...@gmail.com> 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 android-...@googlegroups.com

To unsubscribe from this group, send email to

android-buildi...@googlegroups.com

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 android-buildi...@googlegroups.com.

[Colin Cross]

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")

[John Kaye]

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

[Colin Cross]

Cleaning should be unnecessary.  Just do incremental builds.

[a.m.m...@gmail.com]

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 android-...@googlegroups.com

To unsubscribe from this group, send email to

android-buildi...@googlegroups.com

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 android-buildi...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On Mon, Dec 11, 2017 at 1:50 PM, Jacob Abrams <satur...@gmail.com> 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 android-...@googlegroups.com

To unsubscribe from this group, send email to

android-buildi...@googlegroups.com

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 android-buildi...@googlegroups.com.

[Colin Cross]

Ninja fixes almost all of the incremental build issues because it rebuilds whenever the command line changes, so for example changing LOCAL_CFLAGS in an Android.mk file will rebuild everything that has new cflags.  There were a few remaining corner cases that cause incremental build issues, usually around multiple generated source files that are put in the same directory, leading to old files that are no longer generated being used in the build, but the majority of those should be fixed in P.  The only big remaining issue is that we can't uninstall files that are no longer necessary, so removing a module completely may leave its output file in the final images until you run "m installclean", which only deletes the final installed files and doesn't take long to rebuild.  All of our build servers use incremental for continuous builds, running "m installclean" between each build.  We consider anything that doesn't produce an identical result for an incremental build and a clean build to be a bug. 

[jpud...@littlebox.ca]

I used to use 'mm -B' to figure out which paths a module would touch when compiling without having to dig into the Makefiles themselves.

I'd usually do this to rebuild an test or sample APK I needed for some reason that had already been built, but I didn't know where it was.  I *know* I can figure this out another way, but this was quick and convenient.