zuo will run multiple jobs in parallel, and it will communicate the jobserver to recursive make calls. You can see a transcript here where -j 18 is automatically communicated to the lower levels, including to raco setup: DrDr / R65264 / pkg-src / build / make
Definitely that process (running raco setup) will be the only one running for a large portion of the time, but it will use multiple cores. However, it looks like the jobserver isn't propagating the -j option to raco setup properly and thus it isn't using 16 cores (7 is the process number so it's at least using 7). What is make on your system, and what version of Racket are you building?
Ok, I see this same behavior with the "source" tarball. When I build from the git sources at GitHub - racket/racket: The Racket repository using the top-level make target then I get appropriate parallelism, but if I directly go to racket/src and run configure and then make -j 8 I again get the jobserver warning and no parallelism. So this seems like a bug somewhere in the build system. Probably @mflatt is the right person to look into this.
Thanks for debugging this. I'm sure that with enough eyeballs this can be addressed. When there's a patch, even before the full release, I'd be happy to cherry-pick to make iteration faster.
I've just pushed a change to the makefile stub for racket/src, adding the +s that are needed to propagate -j and jobserver pipes for some versions of GNU Make (especially newer ones). That depends on some post-8.11 fixes already in place at the Zuo level.
Those changes don't address the scheme -q cs/c/ChezScheme/xc-ta6le/s/cmacros.so ... step in building Chez Scheme. The zuofile at that level has two targets: one builds files independently so that they can happen in parallel, and one builds in a single scheme process. The latter is mostly used β imitating historical behavior, which was probably chosen because compilation is so fast when the compiler itself is compiled to native code. When the compiler is running slowly through pb interpretation in the bootstrap phase, though, separate compile processes would probably make more sense. I haven't yet tried changing that.