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
ones you aren't prepared to pick up yourself, anyway. kati seems like something that would be useful to me for a long time even if google wiped every trace of the project they had
1
3
They'll still have uses for it until they've gotten rid of make-based build systems everywhere. Android has been transitioning away from make since 2015. If kati was only intended for Android, it probably wouldn't be hosted on GitHub. It's supposed to become obsolete though.
1
yeah I understand that. I just mean that kati seems so small and self-contained that loss of upstream doesn't practically change that much
1
2
compared to, dunno, android, webkit, even just cmake, which has to run on the OS update treadmill or become unusable
1
2
Yeah, and the GNU make dialect used by actual real world projects is essentially a frozen language. Kati wouldn't need much maintenance. The main areas of improvement would be expanding it to cover more edge cases as needed and optimizing for what other projects do with make.
Similar to how they taught it to understand a subset of the find command to heavily optimize based on it by understanding the dependencies for it. Other projects probably do use find calls that are optimized, but probably not as much as Android. Likely have their own bottlenecks.
1
1
on top of that I'm not sure how inclined would people be to upstream their changes as it is. these sorts of patches tend to be on the ugly side, and their authors tend to not have much free time