Note thatnproc is part of GNU coreutils and may not necessarily be available on all Unix-like systems (namely, macOS). So Mac users should first dobrew install coreutils or usesysctl 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 runmake 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 runmake 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 withmake to not need to be walked through "run./configure && make". There's also the point thatmake -j $(nproc) in the absense of a workingnproc will leave the user withmake -j, which is what we were trying to avoid with this change.

The assumption would be correct if we were in theextension-modules.rst file, but this file is for the "getting started". I don't think we should assume that the reader is extra familiar withmake and even knows aboutnproc 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.