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)
Having a clean DAG still breaks down with recursive Make: if binary X depends on library A, then X's Makefile either has a rule to recurse to A (and then parallel builds of A might happen, even when building from the top level, unless you use -j1) or it doesn't (and then you can only build from the top level Makefile and you might give up parallelism due to granularity of the top-level DAG).
At the time that essay was written, Make was the best runner available, and the only portable one. There are better options now.
fragmede · · focus · HN ↗
<a href="https://accu.org/journals/overload/14/71/miller_2004/" rel="nofollow">https://accu.org/journals/overload/14/71/miller_2004/
Recursive Make Considered Harmful
By Peter Miller
theamk · · focus · HN ↗
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)
entrope · · focus · HN ↗
At the time that essay was written, Make was the best runner available, and the only portable one. There are better options now.