Recursive #includes

[Geoff Leach]

>From article <9752 at smoke.BRL.MIL>, by gwyn at smoke.BRL.MIL (Doug Gwyn ):
> 
> As I remarked in another posting, the problem is that there are logical
> dependencies, with crisp mathematical properties, and physical dependencies,
> which require some actions to update the targets.  "make" unfortunately
> does not distinguish between these, causing lots of grief over the years.
> Some versions of "make" lean more one way than the other, other versions
> vice-versa.  In some sense they're ALL botched.  That's one of the reasons
> you see so many "new make" implementations.  (There are a lot of other
> problems, too, but that's the worst one in my opinion.)
>
> One of the reasons I don't normally show all the dependencies on headers
> in my Makefiles is that "make" simply cannot really get it "right", and
> a "dependency" on a header really is a "might depend" on the header
> anyway, so letting "make" do its thing without manual intervention can
> result in a lot of unnecessary recompilations.  Some object/header
> relationships are obviously sufficiently closely coupled that the
> dependency should be shown, but nested headers may well not need to
> be listed in the Makefile.  It depends on how you conduct your software
> development operations..

Turns out there's a cure for this.  Try "cake", posted to comp.sources.unix,
volume 12.  Not only does it permit the user to program _all_ his/her own
rules, but it also permits the specification of dynamic dependencies.