Paul Smith <[email protected]> writes: > On Thu, 2026-09-24 at 10:28 -0700, Paul Eggert wrote: >> On 2026-07-31 10:42, Bruno Haible wrote: >> > People should be recommending >> > make -Orecurse -j8 >> > instead of just >> > make -j8 >> >> Having tried this when building Emacs I went back to plain 'make >> -j$(nproc)', as otherwise there was too much delay before recursive >> output showed up. > > This delay is fine for build / CI systems, but I agree it's annoying > for "interactive" use. That's why -Otarget is the default option (if > you just use -O), and this is more than sufficient in my experience for > gaining understandable results. Certainly it's much better than not > using -O at all! > > I'm not sure why -Orecurse was suggested. > >> By the way, I wish there was some nice shorthand for 'make - >> j$(nproc)' in GNU Make, to save typing. Maybe 'make -jj'? > > I've thought that something like -j0 could do that. The problems are > partly technical (how do we detect nprocs on all systems that GNU Make > supports?) and partly process: specifically is nprocs really the > correct behavior? There are many situations where it's not a great > idea. > > I wonder if a better way would be to have an option that uses a > combination of -jX and -lY that tried to minimize build time. > > This doesn't help for build environments where the tools invoked have > very large memory requirements; that's the one aspect of system > resources that make has no answer for. > > Or, maybe the perfect is the enemy of the good in this situation.
Gnulib has code to get that on most (all?) platforms that you care about. But I understand you want to minimize dependencies to make it easier to build make without make. If it were in my control, I probably wouldn't implement it for the reasons you mention. E.g., I can build glibc with $(nproc) jobs, but building LLVM with $(nproc) jobs will cause my system to hang due to a lack of memory, requiring me to reboot. Collin
