* On 2026-08-10 at 12:23 BST, Greg Troxel wrote:
Jonathan Perkin <jperkin%pkgsrc.org@localhost> writes:The issue is py-scikit-build-core which is the build system for this. It delegates to cmake and ninja, and ninja ultimately uses all cores by default (and when building 4 versions of py-duckdb simultaneously in bulk builds, 4x all cores on the host, plus all the other builds, which is enough to kill jenkins.jar for me a few times...)I must be missing something. It seems obvious that ninja should run 1 thread only, unless it has been given an argument that means -jN (however ninja spells it). And, that if cmake is invoked, it use 1 thread and ask all child make-type programs to use only 1 thread, unless cmake was given an explicit argument that means -jN. Is ninja deciding to use hw.ncpu or something as a default, but only when run under cmake under scikit-build, because of some environment var, or ? Ninja called from cmake, normally, seems to get this right.
ninja is actually worse than that, it's nproc+2 by default: https://github.com/ninja-build/ninja/blob/v1.13.2/src/ninja.cc#L253-L264 scikit-build invokes cmake directly: https://github.com/scikit-build/scikit-build-core/blob/v1.0.3/src/scikit_build_core/cmake.py#L345-L350 with ninja as the default generator: https://github.com/scikit-build/scikit-build-core/blob/v1.0.3/src/scikit_build_core/builder/generator.py#L90-L105So yes, anywhere we call ninja or cmake ourselves directly in pkgsrc, we ensure the correct flags are passed, but here we have build tools calling cmake themselves without flags, and so things go sideways.
In anticipation of a potential thread: I don't think we should patch ninja. We might disagree with the defaults, but users will expect it to behave like upstream versions. "Why is pkgsrc ninja so much slower than other OS?", etc.
-- Jonathan Perkin pkgsrc.smartos.org Open Source Complete Cloud www.tritondatacenter.com