There's a more general set of reasons that we prefer prebuilts (and are increasingly using them, or building the tools from source during the build):
Asking users to non-default packages works during the first setup, but adding packages to that list means that every user will hit some sort of error message and need to find the instructions again to know what to do. For users that don't administer their own machines (in corporate environments, etc), this can be an even longer process. And if we remove the need for a package, it's likely going to stay on their machines forever. Then there's the problem ensuring that everyone uses the same version so that their build results are the same. When we recommended staying on Ubuntu LTS versions this mostly worked, though was a bit problematic when switching LTS versions. It also meant that we were stuck with whatever (usually old) version was in the LTS, so if it was buggy, or we wanted to use new features, we had to wait. Or if we had code that didn't work with the newer version, a system update could break everyones builds. A similar problem is that we also (somewhat) support building on MacOS, and none of the tools there line up with the version (or for some, implementation) used by the Ubuntu LTS. We're now running a mix of OSes inside Google to build Android -- some Ubuntu 14.04 (some Goobuntu, which is very similar), some gLinux (roughly Debian Testing), and some Mac. Outside of Google I'm sure that list is much longer. Using prebuilts/checked in sources let us produce more reproducible results across all of them, and prevent issues where changes break only some of the builds. We're not quite self-sufficient, but we're moving that direction -- in master, the $PATH inside the build is limited in what can be used: https://android.googlesource.com/platform/build/soong/+/master/ui/build/paths/config.go#76 gives a reasonable idea (though a few of those end up being prebuilts, like java) - Dan On Fri, Jan 25, 2019 at 7:53 PM Robert Durkacz <robert.durk...@gmail.com> wrote: > In response to reported build error, > on Tuesday, October 24, 2017 at 11:20:41 AM UTC+11, Dan Willemsen wrote: >> >> It looks like bison is looking for `m4` in your path, so you'll need to >> install it with apt. We don't currently have a prebuilt of m4 to go along >> with the bison prebuilt. >> > > Is there some reason why Android needs its own version of bison? If not it > is better if we can use a standard version, however the answer given by DW > suggests that they would like to have a prebuilt version of m4 even though > the standard version would work. > > -- > -- > 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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
