| Thanks. > this guarantees correctness, over speed. Wouldn't "promotes" be a better word? what guarantee do you have? > Self-rewriting Makefiles (to consume the .d files), combined with the cleaning necessary for them, become a large technical debt—especially given the complexity of the Makefile needed to generate them. Modern CCen just aren't capable of this. Haven't needed it in a long time, but back when I did generating one for me was all of running the compiler with "-MD" in the compile phase, and including it in the Makefile - no special "make depend" phase, no noticeable slowdown. What technical debt are you ref > Yes. They are both don't provide significantly better correctness guarantees combined with sufficiently better performance to justify the cost to porting to older Unixen. Interesting. It is my experience that redo (from apenwarr) is trivial to run and use anywhere there's Python and isn't Windows -- it's almost as fast as Make, and it makes correctness guarantees that Make cannot (e.g., .o file replacement is atomic). |
My issue with -MD was not that it didn't provide precise (and correct!) dependencies; my issue was that the build system's most mysterious breakages are when modules (and dependencies) are changed. In that case, there are three situations:
1. Your .d files are out-of-date, and thus your build is broken;
2. You have to have a policy of "updating the .d files"; or,
3. Your makefile has to be .d savvy.
The last option is the one I see most often taken, but with rare success.
> it makes correctness guarantees that Make cannot (e.g., .o file replacement is atomic).
I wish Make wasn't so entrenched.