defer
Joined 16 years ago
Joined 16 years ago
The format is not secret either, it's just binary encoded.
The advantage in android is that the different build systems will generate ninja, so they can interoperate.
Android, which uses it for some large component of the system that I've never quite understood
Ninja is really a huge part of AOSP, the build system initially used makefiles. Things got complex really fast with a custom declarative build system (soong) and a failed/aborted migration to bazel. Google developed kati (https://github.com/google/kati) which converts Makefiles to ninja build files (or should I say file), which really is huge: λ wc -l out/build-qssi.ninja
3035442 out/build-qssi.ninja
Going from makefiles/soong to ninja is painful, it takes several minutes even in a modern machine but it simply flies once ninja picks it up.Those stops can be enough to ruin your low latency requirements in the high percentiles. A common strategy is to divide workloads between jvms so that you meet the requirement.
However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.
I build older android (the OS) versions inside docker containers because they have dependencies on older glibc versions.
This is a memory-heavy multi-threaded process and the OOM killer will kill build threads, making my build fail. However, there is plenty of available (but not free) memory in the docker host, but apparently not available in the container. If I drop caches on the host periodically, the build generally succeeds.
But generally, if you pointed that out to me I'd say the same, picking that hardware puts you in a harder path. Also, I'm not sure if Linux users in general have any interest in winning people over.