The latest edition, Issue 8, includes this. Here is an excerpt from the make page: *-j **maxjobs*Set the maximum number of targets that can be updated concurrently. If this option is specified multiple times, the last value of *maxjobs* specified shall take precedence. If this option is not specified, or if *maxjobs* is 1, only one target shall be updated at a time (no parallelization). If the value of *maxjobs* is non-positive, the behavior is unspecified. When *maxjobs* is greater than 1, *make* shall create a pool of up to *maxjobs* - 1 tokens. (Note that implementations are not required to create a pool of exactly *maxjobs* - 1 tokens. For example, an implementation could limit the pool size based on the number of processors available.) If the size of the token pool would be 0, *make* need not implement a token pool.
When all of the following are true: - There is a target with commands that is not up-to-date - The target's prerequisites (if any) are up-to-date - *make* is not waiting to bring the target up-to-date (see *.WAIT*) - *make* is currently bringing a different target with commands up-to-date - *make* is not currently bringing *maxjobs* targets up-to-date in parallel - The special target *.NOTPARALLEL* is not specified - The token pool is not empty then *make* may attempt to remove one token from the pool. If a token is successfully removed, it shall attempt to bring this target up-to-date in parallel, and after this processing completes shall return the token to the pool. When *make* is bringing a target without commands up-to-date, it need not remove a token from the pool. If a rule invokes a sub-*make* either via the *MAKE* macro or via a command line that begins with '+', the sub-*make* is the same implementation as the *make* that invoked the sub-*make*, and the *-j* option is passed to the sub-*make* via the *MAKEFLAGS* environment variable with the same *maxjobs* value and is not overridden by a *maxjobs* value from another source (even if it has the same value), the sub-*make* shall use the same token pool as its invoking *make* rather than create a new token pool. Otherwise, it is unspecified whether the sub-*make* uses the same token pool as its invoking *make* or creates a new token pool. If a rule executes multiple sub-*make* processes asynchronously the behavior is unspecified. On Tue, Oct 29, 2024 at 5:00 PM Steffen Nurpmeso via austin-group-l at The Open Group <[email protected]> wrote: > Rob Landley via austin-group-l at The Open Group wrote in > <[email protected]>: > |On 10/22/24 00:42, Andrew via austin-group-l at The Open Group wrote: > |> Hi, > |> > |> Both GNU and BSD make support parallelism with -j flags. > |> > |> Can POSIX make adopt a -j flag to indicate the maximum number of \ > |> concurrent jobs, default 4? > |> > |> This can help to accelerate a lot of existing makefiles. > |> > |> Cheers, > |> > |> Andrew > |> [email protected] > | > |Why not autodetect? I use -j $(nproc) a lot, although on BSD/mac it's > |"sysctl -n hw.ncpu" instead. > | > |Arbitrary limit seems a bit silly when the ability to probe exists. (The > |linux one even responds to taskset by default, dunno about bsd-land...) > > nproc is broken in namespaces, and the glibc maintainers will not > fix it. I have forgotten other details, responsible persons are > on this list if i recall correctly, though. (A search may show up > bug report(s) (of which there are at least two).) > Ie: no reason for this "even [does] xxx". > 'Must be said, FreeBSD introduced nproc(1) too not too (double > too!!) long ago, maybe that works correctly in jails or wherever > cpusets etc are used. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > | > |And in Fall, feel "The Dropbear Bard"s ball(s). > | > |The banded bear > |without a care, > |Banged on himself fore'er and e'er > | > |Farewell, dear collar bear > >
