AOSP build system is ninja, and that's not my experience with it. It chooses the number of jobs based on the number of hardware threads by default rather than opting in, so if you're comparing to using 1 thread that's relevant. CPU cgroup + SCHED_BATCH helps with this in general.
Conversation
i need to add my specs to that:
7200rpm hard disk, 8GB of DDR3 RAM, 8 core CPU
The ninja part is not a problem at all actually, but when you start a build it has to convert all of the makefiles and bp files into a ninja file which takes *ages*
2
1
It's optimized for incremental builds for developers. It only generates the ninja files for the initial build, and then incrementally updates them if there are changes. It adds a couple minutes to a full build but building the entire OS from scratch already takes incredibly long.
2
1
It doesn't generate any ninja files when you start most builds, because it's very rare that you need to do a clean build. It's something done for production releases, but not so much by developers on their workstations, especially now that incremental builds work so much better.
2
it regenerates the ninja build files whenever you change a makefile or add code files (because that requires changing a makefile) or (with android 8 maybe later too) after midnight every day
1
1
other large software projects like LLVM and chromium do not have that problem on my system, so it's definitely possible to have a performant build system without overpowering systems
1
1
Build a production release of Chromium where LTO is enabled for CFI and it uses far more memory for the linking step than anything in AOSP. AOSP has to link far more than a single binary though, so if you choose to use 8 jobs, you'll sometimes end up linking 8 binaries together.
1
Which build system would go out of the way to serialize the linking phase? I'm not sure what that has to do with the chosen build system for Android. If you only have 8GB of memory, you're just not going to be able to run 8 parallel jobs for builds using LTO. Not AOSP-specific.
1
ninja supports only allowing a certain number of a kind of task (i.e. linking) using its pool feature. It is available to be used with llvm. And yes i know how much pain in the butt building chromium with lto is, but android is somehow *worse*
1
1
also i was initially talking about build system performance, not how demanding the build itself is on my pc. If i run the build command and it takes 5 minutes (with build files already generated) to have ninja start the first command it sucks
1
It takes me 40 seconds to do an incremental build of AOSP with no changes, which is still terrible, but at least 10x faster than it used to be before ninja. I save a lot of time having separate devices for testing signed production builds and test key signed development builds.
The current bottleneck is largely the incomplete transition away from GNU make. There's still a huge amount of build logic in makefiles which has to be converted by kati to ninja files, which takes a long time and generates very sub-par ninja files compared to blueprint / soong.
2
Has been getting a lot better though, and I look forward to when the Android.mk files are completely gone since it's going to improve my quality of life quite a bit. It's far harder for me to analyze those and generate information from them and make is fragile.
Imagine if they did it the right way with each piece of software being its own makefile and stamps to avoid recursing into trees where nothing has changed...
1
Recursive make is awful within a single application, but absolutely the right way to do a "distro" that consists of building many separate software components.