For anyone who ends up with an "argument list too long" error when trying to build Android: run ulimit -s 9999999 first. The maximum command line size on Linux is a percentage of the stack size ulimit.
4
25
144
Conversation
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.
1
2
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.
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
Show replies
Signing a production release and generating the update package, delta update packages and factory images also takes a very long time. I definitely wouldn't want to be doing that as part of development. It's also a waste of time to actually flash an update, or even the images.
1
For development, the best way to test most changes is using userdebug builds, dynamically disabling dm-verity (which is possible on userdebug) and then using adb root && adb sync to sync over the changes incrementally. The ninja build takes a small fraction of the previous time.