That is what he said there - it sounded plausible to me.
systemd-run --user -S -p CPUWeight=1 and build inside the subshell. This works well regardless of build systems, programming languages or (most) AUR helpers.
Instead of limiting the maximum CPU cores (which you can also easily achieve w/ -p CPUQuota=...), setting a low CPUWeight can make use of idle CPU cores when you are not actively using your PC. You can even use CPUWeight and CPUQuota combined when it suits.
I’d always use nice to limit the impact of the load.
I think neither of you have understood the issue I’ve been trying to report.
My issue is NOT about making my laptop cope with compiling on all its cores.
My issue is that building stellarium-lite does NOT honour the MAKEFLAGS and NINJAFLAGS directive.
It has nothing to do with swap, nice level or anything such. The problem is that stellarium-lite build process just IGNORES the MAKEFLAGS and NINJAFLAGS directives. Not anything else.
For short: my system has set the build process for exactly two jobs.
Building stellarium-lite spawns 16 of them, not two.
Look, I have used Gentoo for more than 15 years before and I’m used to build processes. Just not Arch and Manjaro but that’s irrelevant.
I am 100% confident a build process that is supposed to be limited with MAKEFLAGS to exactly two jobs cannot, in any possible way, use all cores. One job is generally limited to one core. So there is absolutely no possible way for two compile jobs to use all (16) of my cores at once. I have never seen such a thing in my 20 years of using Linux, so I’m pretty confident my analysis/deduction is 100% accurate.
Anyway, I’ve spent enough time on this. I just uninstalled stellarium-lite. Case closed.
The issue of CMake spawning more build jobs than set via the -jN/--parallel=N args or via the MAKEFLAGS=-jN env var is apparently caused by CMake’s AUTOMOC configuration and its related settings which are used for Qt’s MOC precompiler (Meta-Object Compiler).
is set, CMake will spawn as many MOC precompile jobs as there are physical CPU cores available on the system for each running build job compiling the respective C++ header files of the Qt-based project. This leads to a build-job multiplication, causing way more parallel build jobs to be run at the same time, choking the CPU scheduler, which in turn makes the system totally unresponsive, despite all build jobs being run at a lower priority.
In my tests that I ran after discussing and figuring out the issue with KDE devs on their development discussion forum, only the Ninja backend (-G Ninja) behaved correctly after the option was set. Using the default Make backend still had the same problems.
That thread also includes links to other Linux distros, as well as FreeBSD and OpenBSD, who all set the CMake option globally in order to avoid this problem.
Can you help me out please? - I’m too dense to figure it out.
Where do I go, what do I do where, to implement that solution that I’m still unable to see?
I’m drawing only blanks when reading through the … solution(s).
