On Thu, Apr 29, 2010 at 3:59 AM, Edward Welbourne <e...@opera.com> wrote: >> Delete a "clean-depend" rule on sight, > > I cannot agree. > If I write a rule to make something, I also write a rule to get rid of > it. It's just basic hygiene ...
I propose the following guideline: If you have a target that generates A (and B as a side-effect), then a 'clean*' rule that deletes B should also delete A (and vice versa). So, I do have a rule to delete *.d files, it's called "clean". Since I don't have rules for building .d files other than with .o files, it Just Works. >> or rename it to the more accurate "break-future-builds". > > If you have a sensible rule to generate .d files when needed, you > haven't broken your builds - you've just obliged yourself to > regenerate .d files. Which may be wasteful, but see below. Okay, so if you have a rule to delete .d files without deleting .o files, you need rules to build .d files. In my experience, the only reason to have *either* of those is "because that's how the Makefile was originally written and the current behavior doesn't hurt enough for me to spend the time to fix it". ... > Speaking of the subtleties of dependency tracking: do an update in > your version control system, watch some header go away - and all files > that used to reference it drop those references. Your .d files claim > a bunch of stuff depends on this missing file; but you have no rule to > regenerate it. So make will not even try to compile anything (even > though everything *would* compile fine) because your .d file say that > all the .o files that need recompiled depend on a file that doesn't > exist any more; make clean-depend fixes that. The fix for that has been documented for years on Paul's webpage, and is most easily done now with gcc's -MP option. > If generating .d as a side-effect, don't listen to the manual's advice > that says you need to sed its content to claim that the .d depends on > the same things the .o does. If those things have changed, the .o > shall be regenerated and hence so shall the .d; and you don't need > this updated version of the .d file to discover that the .o needs > rebuilt. Changes to .h files consequently never trigger re-exec. Ah, it looks like your comments are addressed at just what's in the GNU make info pages and not the advanced method on Paul's webpage. I agree that what's in the info pages has many of the problems you mention...which is why this thread is about updating what's there. Philip Guenther _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make