Recursive #includes

Dave Jones djones at megatest.UUCP
Thu Mar 2 10:48:54 AEST 1989


>From article <9752 at smoke.BRL.MIL>, by gwyn at smoke.BRL.MIL (Doug Gwyn ):
> In article <2538 at goofy.megatest.UUCP> djones at megatest.UUCP (Dave Jones) writes:
>>By what rationale can the first .h be said to depend on the second?
> 
> The first .h depends on the second, because for all X, if X depends on
> the first .h, then X depends on the second.

You're bluffing!

The premise follows from the conclusion, but it doesn't work the
other way 'round. (Show your work in the margin, or on a separate sheet.)

You said in an earlier posting that the conclusion follows from the
transitive  property of "depend", but it doesn't.

I really don't have a clue as to what "depend" means to you, but it's
sure not the way _make_ defines it in the manual or on the man-page,
and which, I might add, is also the way my dictionary defines it:

   "to exist by virtue of some necessary relation."


> That is a logical dependency,
> not a physical one.  No action is required to update the first .h if the
> second is changed (although as someone else pointed out, until a "touch"
> is done on the first .h to "update" it, the effect of changing the second
> will continue to be propagated toward the dependents of the first .h by
> "make", resulting in unnecessary rebuilding of dependents of the first .h).
> 

If you touch the first .h in the rule, then the first .h depends on the
second, and _make_ will function as advertised.



More information about the Comp.lang.c mailing list