El 20/10/24 a las 5:19, Eli Schwartz escribió:
"""
No matter what pools you specify, ninja will never run more concurrent
jobs than the default parallelism, or the number of jobs specified on
the command line (with -j).
"""
Ninja has always tried to scale up very slightly. With >2 cpus
available, it will run $(nproc)+2, with 1 or 2 cpus it will run
$(nproc)+1 jobs.
You are right, it's funny how they chose the wording to say
"the default parallelism" to mean this algorithm:
https://sources.debian.org/src/ninja-build/1.12.1-1/src/ninja.cc/?hl=242:253#L242
If I ask them, they will surely say "this is a feature, not a bug", so I
will not bother. (Seems a controversial design decision to me, at minimum).
Probably I suspect you got this information from ninja's manpage -- if
so you should be aware that ninja doesn't actually have a manpage and
this is a Debian bug in Debian's help2man scripts that replace "on this
system" with the not exactly accurate "#CPUs".
Actually, the manpage was written by hand (not with the aid of help2man)
and this is what it says:
-j N run N jobs in parallel (0 means infinity) [default=#CPUs]
So yes, there is at least a documentation bug here. I'll try to report it.
I should reword my previous claim, then: The build failure seems to be the
result of two things: a bug in the way the dependencies were specified,
and the default behavior of ninja (which is not really to blame for
this build failure, but it has a role for it to happen).
I hope the wrong dependency specification is not too difficult to spot
and fix. In the worst case, we could always pass -j1 as in the latest
patch I posted.
Thanks.
