I'm curious whether this is just an oversight in the build script. I recently ran into the "argument list too long" issue with my shell, and it was because I was using subshells instead of named pipes.
Conversation
like android is pretty much the only build system i know where even just *starting* a build makes your system mostly unresponsive for the next 20 or so minutes
1
1
3
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.
2
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.
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
Show replies