GeezerVison

Note that nproc is part of GNU coreutils and may not necessarily be available on all Unix-like systems (namely, macOS). So Mac users should first do brew install coreutils or use sysctl instead to get the number of physical or logical cores (I don't remember which one nproc returns)

I've merged, as Hugo uses macOS and didn't complain, but we can open a follow-up if need be.

Thanks for pointing that out. I do have coreutils installed via Homebrew, which is why it worked for me. Let's not require or assume others do.

Shall we use a hardcoded value under the macOS tabs? Something like 8 feels like a good default?

TL;DR - this is good enough.

I feel like people who understand how to run make already understand what $(nproc) can be substituted with manually if they don't have the command. if we wanted to be ironic we'd suggest $(python3 -c 'import os; print(os.cpu_count())') to the person who is building python and may not yet have a built python3 (but realistically do anyways because all Linux distros offer it and macOS xcode comes with one). 😛

I feel like people who understand how to run make already understand what $(nproc) can be substituted with

That seems like a rash assumption to me; I would expect anyone with that level of comfort with make to not need to be walked through "run ./configure && make". There's also the point that make -j $(nproc) in the absense of a working nproc will leave the user with make -j , which is what we were trying to avoid with this change.

The assumption would be correct if we were in the extension-modules.rst file, but this file is for the "getting started". I don't think we should assume that the reader is extra familiar with make and even knows about nproc and co (this section would be read by newcomers I think).

By the way, nproc being part of coreutils and not necessarily available on macOS caused some issues in other projects: https://www.drupal.org/project/drupal/issues/3407360. So it's not necessarily a theoretical use case.