Hi, I just discovered a potentially interesting alternative to the ninja build tool: https://github.com/michaelforney/samurai:
samurai is a ninja-compatible build tool written in C99 with a focus on simplicity, speed, and portability. I have yet to investigate and compare it, but the main difference where the interest is clear is "The environment variable SAMUFLAGS can now be used to specify default -j or -v options." Why? If you've ever built something like QtWebEngine from source you must have noticed that that is almost a local DOS attack. Qmake will generate a Makefile through why a python-based build system is launched which in turn calls ninja, all without heeding $build.jobs which gets thrown out in the first (g)make level. I don't have definitive proof but I'm pretty certain that some of the ninja files spawn other ninja jobs, meaning you end up with multiple copies running that all think they can launch way more jobs than they should. And those jobs aren't small bites either: clang++ can get very memory hungry on larger C++ files (not to mention ObjC++!). In practice, you end up with a build that may actually complete quicker and allow the system to be used for (light) other tasks in the meantime if you force a hard limit of say half the available CPU cores on the number of jobs ninja can use. The typical "port:samurai scenario" would be to make it conflict with ninja, and make $prefix/bin/ninja a symlink to idem/samurai. I'm planning to try this and build QtWebEngine on a machine I'm not using much these days, just to check if the build completes. If it does then port:qt5-qtwebengine could use `depends_build path:bin/ninja:samurai` . R.
