[ 5% 2127/35727] there is nothing in the world more helpless and irresponsible and depraved than a woman rebuilding android on a laptop with a U-series CPU
8
11
176
Conversation
you know things are bad when the /build runner process alone/ consumes 2 GB of physical memory
5
65
Replying to
and like it doesn't do that because it runs on a jvm or something. it's a nice and efficient build runner ... that happens to run a build where the text file with the build is 1.4 GB in size
1
2
Replying to
honestly it's not unreasonable to have it all in one file. it's like "recursive make considered harmful" but for an entire os. it's just... big
note: this doesn't include chromium. chromium alone is larger and builds for longer than the entire goddamn os
2
2
Replying to
even if it is a whole ass modern os i personally see having a build file that huge as an utter failure on multiple levels.
3
It's the backend ninja-based build system output. The frontend build systems produce it. It happens that way because the entire OS is built together with very few components being built separately. Linux kernel and Chromium are built separately with AOSP itself.
1
Forks like LineageOS tend to build the kernel with a nested build system inside the main one instead of using a prebuilt. If they actually integrated it into the normal build system instead of using a nested one, it'd end up increasing the size of the ninja input substantially.
Also, not everything is migrated to the declarative build system yet. Still quite a bit of pseudo-declarative Makefiles that are designed to be treated as a single massive Makefile and get translated to ninja by kati. It's a lot more efficient with most of that replaced in R.
1
2
> If they actually integrated it into the normal build system instead of using a nested one, it'd end up increasing the size of the ninja input substantially.
It would built a lot faster though, particularly for incremental builds. GNU make is a horrible GNU make implementation.
1
1
Show replies