The `-j` is meant for the top-level invocation only, and the $(MAKE) pattern is standard.
The `+` or $(MAKE) "tricks" to ensure the jobserver is inherited in submake and any other subprocess are no longer needed in gmake 4.4 (from 2022) because it defaults to a FIFO instead of pipes. The author should just upgrade gmake :).
[2026-10-01 9:35:10] % which make
/usr/bin/make
[2026-10-01 9:35:39] % /usr/bin/make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
If you have sub-projects which cross-depend on each other (no total ordering), then recursive make will have a bad time. I agree.
Author thinks the best way is to stop doing recursive make. I disagree.
IMHO, the best way to solve this is to arrange your sub-projects properly, so the are no circular dependencies and thus there is one correct order. Not only your build should be a DAG on file level, it should also be a DAG on the sub-project/directory level. Then a single recursive "make" pass builds everything properly, no need for ugly tricks like running make twice, or intentionally omitting some dependencies.
(Even better option is to stop using make for such large projects - it's great for smaller ones, but for the huge ones, there are much better runners available. But I assume there is some reason to use make)
Yeah, no: We use recursive make extensively with a mix of "just normal makefiles" and autoconf schtuff, and it all works fine and reliably.
It's like any programming: Understand your tools, understand your requirements, understand your design and implementation (code carefully), test, review the design and implementation, test, repeat as necessary.
Still a big fan of make all these decades later. One day I may reach BJJ blue belt level.
The proliferation of recursive make has been harmful for make itself!
Most of the make replacement tools are promoted by propaganda which attacks a strawman version of make, whereby it is assumed to be at the center of a shitty recursive situation.
The `+` or $(MAKE) "tricks" to ensure the jobserver is inherited in submake and any other subprocess are no longer needed in gmake 4.4 (from 2022) because it defaults to a FIFO instead of pipes. The author should just upgrade gmake :).
https://accu.org/journals/overload/14/71/miller_2004/
Recursive Make Considered Harmful
By Peter Miller
If you have sub-projects which cross-depend on each other (no total ordering), then recursive make will have a bad time. I agree.
Author thinks the best way is to stop doing recursive make. I disagree.
IMHO, the best way to solve this is to arrange your sub-projects properly, so the are no circular dependencies and thus there is one correct order. Not only your build should be a DAG on file level, it should also be a DAG on the sub-project/directory level. Then a single recursive "make" pass builds everything properly, no need for ugly tricks like running make twice, or intentionally omitting some dependencies.
(Even better option is to stop using make for such large projects - it's great for smaller ones, but for the huge ones, there are much better runners available. But I assume there is some reason to use make)
It's like any programming: Understand your tools, understand your requirements, understand your design and implementation (code carefully), test, review the design and implementation, test, repeat as necessary.
Still a big fan of make all these decades later. One day I may reach BJJ blue belt level.
Most of the make replacement tools are promoted by propaganda which attacks a strawman version of make, whereby it is assumed to be at the center of a shitty recursive situation.