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 :).
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.
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)
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 :).
Has Apple backported anything recent to their forked gmake? Have they ever backported any features for that matter?
Don't do it!
https://accu.org/journals/overload/14/71/miller_2004/
Recursive Make Considered Harmful
By Peter Miller
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.
Disagree on main premise of that.
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)