Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!fernwood!yasc!geoff
From: geoff@yasc.PLA.CA.US (Geoff Leach)
Newsgroups: comp.lang.c
Subject: Re: Recursive #includes
Message-ID: <238@yasc.PLA.CA.US>
Date: 2 Mar 89 04:37:58 GMT
References: <9752@smoke.BRL.MIL>
Organization: Yet Another Software Company, Palo Alto CA USA
Lines: 24

From article <9752@smoke.BRL.MIL>, by gwyn@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.