Recursive #includes

[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.  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).

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..