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
That's a rather bad default if the limiting factor is going to be memory rather than cpu...
1
1
The limiting factor is definitely CPU for most workstations purchased to do this kind of compilation. Using a single job would definitely be a worse default. Hidden serialization enabled by default would also be pretty bad. Dev time is way more expensive than a good workstation.
2
I think it's a good thing to default to making maximal use of hardware, since people will realize they don't have enough memory for it to work or be efficient vs. not realizing they need to pass assorted options to make good use of the hardware. I think it doesn't go far enough.
1
There are a few places where it limits a number of jobs to half of the available hardware threads, etc. and I find this annoying because sometimes that's the only thing being rebuilt and it's not taking advantage of HT. I value my time a lot more than the cost of some more DDR4.