Conversation

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.

144

Replying to

and

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.

Replying to

and

"Oversight" is a very kind way of putting "they NIH'd an utterly hideous build system just because they couldn't be bothered to understand how good existing ones are supposed to work".

Charlotte

(moved to @charlotte@akko.chir.rs)

Replying to

and

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

Replying to

and

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.

Replying to

and

That's a rather bad default if the limiting factor is going to be memory rather than cpu...

Replying to

and

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.

12:32 PM · Oct 22, 2019Twitter Web App

Charlotte

(moved to @charlotte@akko.chir.rs)

Replying to

and

llvm allows users to opt into running linking steps serially. by default it runs them like any other task

Replying to

and

LLVM consists of very few, very large components vs. a drastically larger number of components varying quite a bit in size and compile options. CFI/LTO is currently only enabled for a certain subset too. It'd be a lot more complicated to come up with useful opt-in serialization.

Show replies

Replying to

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.

Replying to

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.