> 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 with the current stiff it is even worse.
make depend won't regenerate the .depend file for either target,
as least the autodepnd manages it for one of them.

If g.h is switched from including h1.h to h2.h (forcing a rebuild),
the autdep will rebuilf f1.o when h2.h is changed.

	David

-- 
David Laight: david@l8s.co.uk