On Wednesday 30 May 2001  6:32 am, Simon J. Gerraty wrote:
> >> 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 :-)

Surely it'd be better to keep them seperate (yes there's a bit more over 
head, but nothing compared with the delights of forking a new process for 
every directory)  As they can have an automatic dependancy on the same files 
as the .c file, so they update as appropriate.  It also means should a file 
get deleted make doesn't get confused by having dead files in the .depend 
file.

If we've got missing functionality like the above, perhaps we should look at 
implmenting it.

> >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 ;-)

can't the .ly thing be done implicitly, IE we have a rule that generates a .c 
and .h with the same name?

> >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.

Another major thing that think of that could be useful to do (especially for 
the slower machines) would be getting rid of recursive makes, as the forking 
overhead of make, and the fact it then reparses all the same files it's 
already parsed etc, is huge. *sigh*

A couple of related things on the net about make/gmake:
Auto dependacy generation: http://www.paulandlesley.org/gmake/autodep.html
Recursive make considered harmful: 
http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html

Note I have used the auto dependancy stuff on a real project, and it made 
life so much easier.

Cheers,
Chris