I already replied to some of this.
On Thu, 2024-10-31 at 14:48 -0500, Rob Landley via austin-group-l at The Open Group wrote: > > It's also more efficient to query an OS API than to create a new > > process and parse the I/O streams. > > Which is why I was suggesting that "make -j" detect it, via whatever > mechanism the other commands are using, so you don't have to specify > it on the command line. > > The current behavior of gmake is that -j without a number (I.E. the > next argument is not a number, which is gnu/terrible UI design but > decades established by now) will forkbomb the system: This option of "-j" with no arguments IS commonly used by GNU Make users so it can't be changed now. But you're right, it doesn't make much sense to use by itself except in trivial makefiles where you know that it's not possible to get large numbers of parallel jobs. Instead, it's used with -l; for example: make -j -l4 This is arguably a much more reasonable way to handle parallelism anyway, than using a fixed number of jobs. Although of course it's still dependent on the number of cores to get the right value, due to the way load is calculated on POSIX systems. I also agree that optional arguments like this are a design mistake. I don't think we should ask POSIX to perpetuate it by making <maxjobs> optional. Previously I recommended using a special value, such as "-j0", to mean "best guess". Or, we can allow word arguments like "-j nproc" or similar in addition to integer values; even math like "-j nproc+2" or "-j nproc-1" or something. But simple "make -j" with no argument choosing some value, whether based on hardware or defaulted, isn't going to work for GNU Make.
