You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: macOS build instructions use unavailable nproc command #1959
The CPython Developer's Guide currently instructs contributors to compile CPython using the following command in getting-started/setup-building.rst, under the Unix build instructions:
make -s -j $(nproc)
However, nproc is a GNU coreutils utility that is not available by default on macOS.
When a contributor follows these instructions on a standard macOS installation, the shell reports:
zsh: command not found: nproc
As a result, the command substitution produces an empty string, effectively executing:
make -s -j
Without an explicit job count, GNU Make allows unlimited parallel jobs. This can result in excessive resource consumption during compilation.
Expected Behaviour
The build instructions should provide a macOS-compatible command that determines the available logical CPU count without requiring additional utilities.
Proposed Solution
Introduce separate Unix and macOS tabs for the compilation command, following the existing documentation conventions in:
getting-started/quick-reference.rst
development-tools/sanitizers.rst
Keep the existing Unix command:
make -s -j $(nproc)
For macOS, use:
make -s -j $(sysctl -n hw.logicalcpu)
This would allow macOS contributors to build CPython using the available logical CPU count without installing GNU coreutils.
Additional Context
A similar macOS compatibility issue was previously addressed in PR #1545, where nproc was replaced with a fixed job count in another section of the documentation.
However, the primary compilation instructions still contain the incompatible command.
This issue proposes applying the existing macOS-specific approach consistently to the main build instructions.
I noticed that PR #1964 is currently under review. I'm also interested in contributing a fix for this issue and would be happy to take it forward if the current PR becomes inactive or if an alternative implementation is needed.
I'll avoid submitting a duplicate PR while #1964 is being reviewed.
Activity
lokeshsahu2804-korba commentedon Nov 4, 2026
Thanks to everyone who has worked on this issue.
I noticed that PR #1964 is currently under review. I'm also interested in contributing a fix for this issue and would be happy to take it forward if the current PR becomes inactive or if an alternative implementation is needed.
I'll avoid submitting a duplicate PR while #1964 is being reviewed.