>> Not quite the same thing, but I have an autodep.mk, which adds -MD to 
>> CFLAGS and gathers the *.d files thus produced into .depend.
>> This does not solve the problem of foo.h no longer being relevant (or
>> existant), but for the most part dependencies are kept up to date
>> for very little effort.  Sure beats running "make depend" on a large tree.

>Interesting! 

>I presume you gather the .d files so that there's only one file for make
>to open (esp. in the case where not all source files are re-compiled).

Yep.  Its a pitty that we can't do .include "*.d" like gmake :-)

>Are there any other issues?  Eg. what do you do about dependencies on
>intermediate sources (eg. yacc output)?

In the original autodep.mk (which is included in the macros that 
go with bmake btw), I simply relied on the fact that .[ly] can be turned
into .c's.  This is really only an issue when doing an explicit
"make depend" which I hardly ever do.  In normal processing the Makefile
already has a graph that will cause a .o to be produced from a .[ly] 
and when that happens the .d file will be produced - and the right 
things seem to happen ;-)

>Have you implemented this in the system source tree and compared it
>against "make dependall" in any subset of the tree (esp. perhaps lib or
>even just lib/libc?)

Not our src tree, but yes it is in regular use for an equivalent tree
the right things seem to happen :-)  IIRC I did use autodep early last
year when doing some full make release builds of our tree.

>I wonder how hard it would be to concoct a rule that allowed you to
>effectively back up a step when a missing dependent is encountered in

My head hurt just parsing that, so I'll punt :-)

--sjg