
Android now builds with Ninja instead of Make - evmar
https://groups.google.com/d/topic/android-platform/Hhl_4hfOONg/discussion
======
voltagex_
Text for those who can't/won't log in for it:

    
    
      AOSP master platform builds now build with ninja instead of GNU make. 
      The build/core makefiles and Android.mk files are read by kati 
      (https://github.com/google/kati/blob/master/README.md), which will 
      interpret them and write out a $OUT_DIR/build_$(TARGET_PRODUCT).ninja 
      file, and then the execution of the build rules will be handled by 
      ninja (https://martine.github.io/ninja/). 
      
      Building with kati and ninja provides some immediate benefits: 
      1. Faster startup time for new builds. Running kati and then ninja 
      results in builds starting about 25% faster than GNU make. 
      2. Much faster incremental builds. kati caches the mtimes of files 
      and directories it read, what environment variables it used, etc., and 
      only re-reads all the makefiles if something has changed. This 
      includes globs like $(call all-files-under). Incremental builds with 
      a warm disk cache will start within 5 seconds. 
      3. Better build command output. Ninja buffers the output of each 
      command and prints it without mixing output from multiple commands, 
      meaning error messages will be printed as a group after a build 
      failure, and not mixed with other concurrent build output. Ninja also 
      prints a configurable status line that defaults to printing the 
      percentage of build commands that have been run, the number that have 
      been run, and the number that need to run, giving a reasonable 
      approximation of the progress through the build. 
      4. Incremental builds should be more reliable. Ninja considers 
      outputs whose command line has changed to be dirty, which will catch 
      changes to global cflags, etc. and rebuild anything that has changed. 
      
      The use of ninja should be transparent, it is wrapped by the top level 
      Makefile, so all make-based commands should continue to work. 
      
      These changes are a precursor to a much larger change that will 
      replace all the Android.mk files with data files using a format that 
      provides much better error checking, even faster builds, and 100% 
      reliable incremental builds.

~~~
e12e
I appreciate the sentiment, but now I have to side-scroll to read ;-)

Maybe I'm just using an unusually large font for reading hn, but I find that
<pre>/indented/code blocks on hn are best limited to around 50 character width
- preferably a little less - to avoid scrollbars.

~~~
easytiger
if you can't get 80 columns in your viewport you need to go back to 1974 and
start using 80c wide punchcards.

~~~
erikpukinskis
This may blow your mind, but I code in 40 columns. By choice. It's amazing.

~~~
easytiger
only if you write in APL is this acceptable

~~~
erikpukinskis
I write in JavaScript.

------
rwmj
"ninja" seems to refer to this:
[https://martine.github.io/ninja/](https://martine.github.io/ninja/)

Can anyone summarise the benefits of this build system vs make? According to
the manual, just speed (why didn't they just work on making "make" faster?)

~~~
evmar
The post (quoted above in a comment) describes some of the features the
Android engineers liked.

This old post from when Ninja was first released discusses "why not just
improve make":
[http://neugierig.org/software/chromium/notes/2011/02/ninja.h...](http://neugierig.org/software/chromium/notes/2011/02/ninja.html)

With another four years of perspective, I think the things Ninja does could
not have been added to make without forking Make (perhaps even the build file
syntax), at which point there's little point in starting with the Make code.
For example Ninja builds in parallel by default (like the -j flag to Make);
you couldn't make that change in Make because existing users have builds that
don't work in parallel.

(Disclaimer: Ninja author, no involvement in the Android work.)

~~~
rwmj
You could just set MAKEFLAGS=-j<N> in the environment. I have this in my
.bash_profile:

    
    
        export MAKEFLAGS=-j$((`nproc` + 1))

~~~
reubenmorais
As evmar already mentioned, lots of projects don't support parallel make.

------
lobster_johnson
I thought Google was all about Bazel these days. Anyone know why Google is
pushing two apparently competing build systems?

~~~
skybrian
Only two? There are more than that. For example, Android Studio uses Gradle.
Go and Dart have their own build systems as well.

It might be because Google is a big company doing many things in many
languages, Bazel was only open sourced recently, and so on.

~~~
sunnyps
Don't forget Chromium which itself has two meta build systems (gyp and gn -
similar to bazel/cmake/etc.) along with an underlying build system (ninja)
which can target multiple compilers and runtimes on different platforms.

P.S. Chromium is in the middle of a transition from gyp to gn[1] which is why
it has two build systems.

[1]
[https://chromium.googlesource.com/chromium/src/+/master/tool...](https://chromium.googlesource.com/chromium/src/+/master/tools/gn/README.md)

~~~
frik
Good to hear the move away from gyp. The hand tuned build scripts
(VS/nmake/make) before gyp were better.

------
swiley
As if building android didn't need more bizarre dependencies setup.

------
jheriko
how long until they get it to build properly i wonder? XD

sorry... just can't help but poke fun at these tools i've never needed except
in the linux environment.

every time i get something from google and need to build it its a nightmare of
poor build experience. good to know they are making an effort to improve
things.

one click build ffs.

~~~
swiley
And how exactly do you build your projects? Msbuild? That's a 2 (4?) GB
download.

~~~
darklajid
I agree that the GP wasn't .. coherent. But I don't understand your comment.
msbuild resides in (for example)
C:\Windows\Microsoft.NET\Framework64\v4.0.30319

What would you need to download? It doesn't seem to be part of VS if that's
what you were suggesting.

~~~
johncolanduoni
That version of msbuild isn't fully compatible with the one that lives in VS's
folder, even when VS is installed. I've had it fail when trying to use it to
compile stock projects made by Visual Studio, without anything fancy in the
scripts.

