On Wed, Apr 28, 2010 at 7:12 AM, Edward Welbourne <e...@opera.com> wrote: >> It's also unnecessary - you don't need a rule for %.d at all. You can >> just generate the dependencies as a side-effect of compilation using >> -MMD or similar. > > Well, if a .d file gets deleted while its .o file exists, you do need > to regenerate it - or regenerate the .o (which may cause wasteful > knock-on actions since it's now newer than it was, even if unchanged). > This matters if, for example, you have a make clean-depend rule to > purge dependency information.
Delete a "clean-depend" rule on sight, or rename it to the more accurate "break-future-builds". I can think of absolutely no reason to delete dependency files without deleting the objects they describe. >> Then use '-include' to grab all the deps if they exist. > > better: include only the .d files that correspond to .o files *that > exist* - if the .o file doesn't exist, you don't need to know what it > depends on, aside from the primary source from which it's compiled > (which is indicated by the pattern rule that makes the .o file). Yeah, that's true. Nice. >> By providing a rule for the .d files you'll cause make to >> re-execute itself, so you'll just end up parsing the Makefile twice. > > Only if you include .d files that aren't really needed (which is > common practice). There's still the case of a .o and .d pair that both exist where the .o is out of date to one of its dependencies. If the .d file is a target, then make will first rebuild the .d, re-exec, then rebuild the .o. The re-exec is unnecessary there; building the .d as a side-effect of building the .o is sufficient. Philip Guenther _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
