It uses lower time complexity algorithms, avoids lots of unnecessary work and has built-in implementations of commonly used shell commands.
It has clever things like a built-in $(shell find) where it can track the timestamps of those directories and avoid running find again.
Conversation
It's not just that ninja is faster but that it's a much faster implementation of dealing with make. It's not an entirely complete GNU make implementation and they take the practical approach of requiring minor build system adjustments. It's also more reliable than GNU make.
1
9
It's clever enough to realize that it needs to cope with environment variables changing, etc. compared to GNU make where if you change CFLAGS, it's not going to realize that it actually needs to rebuild everything. It was made as a stopgap while Android moves to Blueprint files.
1
8
I think it would be very useful for many people outside of Android if they knew it existed. There are a lot of other neat tools like this in Android and Chromium. They're huge projects and they come up with some really nice tooling to deal with real problems in a practical way.
3
2
10
In a typical google opensource project fashion, Android is getting rid of it
blog.bazel.build/2020/11/12/aos
2
3
fwiw I think it's a right decision, bazel excels at massive multi-language projects like that, it's just a bit stupid that they didn't do it right away.
1
1
Bazel was only open sourced in 2015. Android couldn't use a closed source, internal tool for the build system. Android's make-based build system is much older. The newer declarative build system started development before Bazel was open source. Could have coordinated that better.
2
2
Oh, I wasn't aware kati was that old. Makes more sense then. Still a bit sad considering all the work various open google projects did with their build systems because they couldn't do bazel yet.
1
1
They still would have wanted kati to transition Android away from the make-based build system to Bazel. They would have ideally implemented support for building it with Bazel instead of making soong / Blueprint which are basically a reinvention of Bazel with strong AOSP support.
1
If Bazel had been open source a year or two earlier, AOSP could have used it. They'd still have needed to develop most of the same stuff, but for Bazel instead of their reimplementation. Similarly, if it was open sourced even earlier, they could have avoided gradle for the SDK.
1
1
Chromium could have avoided making gyp and then gn. At least in Android's case, they have a straightforward migration path to Bazel because they closely followed the design. I think it's hard to open source internal projects in general, especially due to the inter-dependencies.
In chrome's case it's even harder actually, bazel's windows support was somewhere between nonexistent and severely lacking for a really long time
en.wikipedia.org/wiki/PowerShell and en.wikipedia.org/wiki/.NET_Core are both examples of this painful process where open sourcing something leads to needing to reimplement internal things, often in a very incomplete way, and the internal project keeps living alongside it until it's good enough.
1