Subject: Re: "Soft" make dependencies? Was: make build problem - BIND
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 05/30/2001 00:55:56
[ On Monday, May 28, 2001 at 17:35:26 (-0700), Simon J. Gerraty wrote: ]
> Subject: Re: "Soft" make dependencies? Was: make build problem - BIND
> 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).
Are there any other issues? Eg. what do you do about dependencies on
intermediate sources (eg. yacc output)?
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?)
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
any generated portion of the makefile (i.e. in the .depend file) and
then do a local "make depend" (maybe even just for the necessary
target(s)), and finally re-exec 'make' again. I suppose the basic
smarts for this might have to be built into make with appropriate hooks
so the makefile could manage the process (otherwise how do you know that
make encountered a missing dependent that was only mentioned in an
On the other hand this whole problem smells a lot like "recursive make
considered harmful"! :-)
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>