Ninja is a carefully tuned system that befits the name "software engineering". I highly recommend reading Ninja chapter of the book The Performance of Open Source Applications.
You can speed it up somewhat by tweaking ~/.gradle/gradle.properties and adding org.gradle.daemon=true
and org.gradle.parallel=true. That way at least it doesn't have to re-read all the build files each time and will run some parts in parallel.
The benefit wrt the old Ant-based build is the way it lets you specify 3rd party dependencies. Being able to just add in say Timber, ButterKnife and Guava with a few lines of config, rather than downloading the jars, faffing with paths, making sure the pre-processing bits are in place, etc, is really a big benefit. Maybe Maven would have been a more sensible choice, since Gradle/Groovy seems pretty niche and not really used that much outside Android.
Using files as an API is one of the most generic interfaces you can get. You can use it from any system/language you can imagine, assuming it can write to a file.
The files serve as a cache of the output of the build file generator: each time the user executes a build (e.g. after each edit to a source file) you only run ninja, not the generator program.
As someone who has used make a lot, screw writing makefiles. It's too low-level and I want to be able to build my stuff without lots of headache on multiple platforms (which includes Windows). I hate CMake's weird language, but even that beats makefiles.
A Ninja file is probably no easier to write than a Makefile. But Ninja is a lot faster than make, which is the reason for using it. To see this, configure Chromium to build with Xcode, make, and ninja, and compare the build times.
Adding to this, from what I understand, ninja was designed to be generated by another more feature-full build tools. For example in chromium, its generated from gyp (generate your projects) files. The fact that its human readable is just a plus.
Makefiles I presume, will be hard to write by hand when:
1. Your project code base is large
2. It take large amount of time or very powerful machines to build sub-modules (V8 for e.g in chromium) so, you don't want to do it all the time
3. Conditional inclusion of sub-modules (for iOS vs Android if you have two separate set of files etc)
4. Sub-modules are pulled in from 3rd parties into your code base
I once wrote a custom build systems in python to generate Make files. I did this because I wanted to use convention instead of configuration and achieve fast builds on multicore machines. Later, after leaving that company, I wanted to recreate a similar build system. I wrote it in python to generate Ninja build files.
I found it easier and cleaner to write Ninja build files.
I wasn't able to do a direct comparison of the build speeds of the two systems, but I bet the Ninja builds were significantly faster.
Sigh. As far as I can tell ninja is primarily used as a cmake backend. Mostly because the people who wrote cmake never learned to write Makefiles and as a result using ninja with cmake is much faster.
Actually it's more like a "second step" for make. You can use make to generate ninja files, and then ninja does the actual build. The idea is that make makes a lot of decisions that (usually) stay fairly stable as the files change gradually. Obviously CMake and various other build tools can also generate the .ninja files too.
e.g Make/CMake decides whether you're doing a debug or release build, and builds the appropriate ninja files. Ninja then doesn't have any decisions to make, other than purely what to build, which makes it fast.
It's used for Chrome/Chromium, and I believe the "no-op" build time is still under a second. If you then change a .cpp, it will only compile the absolute minimum, and calculation as to what to build is incredibly fast. make is considerably slower on the same set of files (so they say, not tested it personally, but the figures are around somewhere).
If you need a multi-platform build system that runs on Windows, OSX, Linux, supports the platform's native compilers, and that also works for IDEs, GNU make is simply not an option. Then add cross-compiling to Android, iOS, emscripten, NaCl, game consoles etc... and cmake suddenly looks really nice. I've been using manually written makefiles years ago (around end of the 90's), but then also had to support Visual Studio projects, so I wrote a Tcl script which could generate makefiles and Visual Studio project files from the same project description, this soon became a problem because I also wanted to use Xcode and Linux IDEs, and also because Visual Studio project files change between versions. Cmake does the same and much more (there are also other, similar systems like scons or premake, but cmake seems to have "won"). CMakeFiles ain't pretty, but I never encountered a build problem (including more complex stuff like code generation or running custom build steps) I couldn't solve without pulling my hair out, and everything works automatically across IDEs and platforms.
If you measure by "number of users of the resulting binaries", Ninja is primarily used as a backend for Chrome's bespoke build system. But by number of projects, cmake is likely dominant.
(And yes, part of the reason Ninja succeeded is because it ties the hands of the person generating the files. Make gives people enough rope to hang themselves and they frequently do. From the manual: "To restate, Ninja is faster than other build systems because it is painfully simple. You must tell Ninja exactly what to do when you create your project’s .ninja files.")
...but you categorically cannot argue that Kitware has single handed transformed the entire C++ build infrastructure landscape; the brand new cross platform IDE by JetBrains (CLion) uses cmake as their primary build method.
You have to tip your hat to the fact that KitWare been fantastically successful in their mission.
Like it or not, it's a fact. Cmake is here to stay.
Make could have been a contender, but the only people who cared enough about it to actually build anything useful with it, built automake; which is a piece of stinking rubbish, not portable, and has a syntax even more arcane than make OR cmake.
Maybe if android and the google make toolchain had arrived 4 years earlier, we'd be somewhere else now, but the gate is closed now. Make is obsolete as a build system for a modern project that has to, you know, actually compile on multiple targets.
I disagree, and think they've done a great job. The CMake devs have always been really responsive to bigish projects that find CMake to be almost-but-not-quite good enough for their project, adding in missing autotools features or other semi-commonly used bits and bobs.
They manage to keep up with all the churn in the world of compiled software, whereas it would be so easy to let a tool like CMake bitrot. Old mistakes have sensible deprecation policies too, so they have managed to avoid the accumulation of cruft that could have brought it to a standstill.
I still think build systems should be written in node and js from now on. Node is easy to install on most environments, in my experience it is much easier than python or ruby and javascript knowledge is spreading.
http://aosabook.org/en/posa/ninja.html