Subject: Re: "Soft" make dependencies? Was: make build problem - BIND
To: None <email@example.com>
From: Simon J. Gerraty <firstname.lastname@example.org>
Date: 05/29/2001 22:32:59
>> 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.
>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 :-)