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.
the ninja file is also very large so that ninja takes >1GB at all times. running m is painfully slow on my system
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
Show replies