>> I.e autodep has proven to be a net win.
> i've been trying to figure out exactly when one would lose with this
> method and i've not come up with anything yet..

Source files f1.c and f2.c include g.h.  There is a g.h in this
directory and another in some other directory later on the include
search path (perhaps a system directory, perhaps in a -I directory, it
doesn't matter).

Now, let's say someone notices that the g.h facility is (now) provided
by the g.h in /usr/include (or ../include or whatever) and destroys the
local g.h.  This someone notices this while fixing an unrelated bug in
f2.c.  Now, f1.o will not be rebuilt - nothing it depends on has
changed, except for g.h vanishing.  f2.o, however, will, and while the
API hasn't changed between the now-destroyed local g.h and the other
g.h, the backend has, so f1.o's use of the backend does not get along
with f2.o's use of it (consider what would happen if two stdio-using
modules differed on the order of the elements in a FILE for the sort of
fireworks I'm imagining).

Admittedly, this is contrived.  And I make no claim (either way) about
whether this risk is worth the benefits autodep brings.

But you did ask, and it's about all I can come up with short of people
backdating files with the likes of touch, which can break any
dependency scheme that depends on file dates.

I think this could be fixed by convincing make to consider a missing
optional dependency as always newer than the target - it may need
another flavour of optional, but it could be done, and it would fix
this (because f1.o would always be rebuilt when anything it used to
depend on has vanished, fixing the dependency information in the
process).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B