I honestly consider any project that is complex enough to require more than a single trivial makefile (eg. lua, say) to be unsuitable for using make at all.<p>Everything else I've seen that tries is exactly as bad as this paper suggests.<p>This 'modern makefiles' stuff from the android NDK is one of the worst offenders; those makefiles are almost without fail difficult to debug and problematic (just search SO for 'ndk', 'makefile' if you don't believe me), but because it's android, I've actually had people advocate we use that approach for other projects too.<p>Craziness.
The last project I worked on used recursive make. I did a lot of work on that system to get the damn thing to build properly. However at the end it did work, and just as well as an include-based make we've used on previous projects.<p>He mentions in the paper that dependency generation using gcc -MM, well you can do the same in your recursive system with roughly the same amount of pain. And (I do hate to say this) some of the other concerns are really rather inconsequential with the speed of modern computers.<p>It's a very good paper and it provides good insight into the problem space, but I'm not sure it's an absolute. See also '"Considered Harmful" Essays considered harmful' - <a href="http://meyerweb.com/eric/comment/chech.html" rel="nofollow">http://meyerweb.com/eric/comment/chech.html</a><p>On balance I think include-based make is probably a better way of doing things, and you can still have your module level files, they just become included rather than executed.<p>Of course what all this fussing about with dependency scripts really shows is that what most people try to do with make could be automated by other systems.
Surely maintaining a single build file for enormous code projects worked on by many different teams would cause more harm than good?<p>The paper writes this issue off as 'same stuff in one or many files, same complexity', but obviously this isn't the case when multiple teams are involved who don't understand the work or requirements of other teams. The paper feels far too theoretical and is likely why nobody has taken much note and recursive makefiles are still the most used form for very large projects 10+ years after the paper.
Nobody wants to write Makefiles and recursive Makefiles are easier to write.<p>If it's truly the same information in multiple recursive Makefiles as it would be in one monolithic Makefile, then there should be a tool that converts recursive makefiles into monolithic makefiles. Humans should not have to reason about the entire project scope at once.
I would call this nested Makefiles. Recursive Makefile is more what I'm doing with my MakeHereCMS, where every Makefile is a symlink to the same top level Makefile.