Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!ernie.Berkeley.EDU!jas
From: jas@ernie.Berkeley.EDU (Jim Shankland)
Newsgroups: comp.lang.c
Subject: Re: Recursive #includes
Message-ID: <28256@ucbvax.BERKELEY.EDU>
Date: 1 Mar 89 22:51:59 GMT
References: <9736@smoke.BRL.MIL> <2538@goofy.megatest.UUCP> <9752@smoke.BRL.MIL>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jas@ernie.Berkeley.EDU (Jim Shankland)
Organization: University of California, Berkeley
Lines: 57

In article <9752@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <2538@goofy.megatest.UUCP> djones@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.

This sounds a little funny (well, wrong).  Dependency is a binary,
transitive relation D(a, b).  It means:  "a is functionally dependent
on b.  If the value of b changes, the value of a is likely to change as
a consequence."  You can't conclude that because for all X, D(X, h1)
implies D(X, h2), therefore D(h1, h2) is the case.  You might come up
with some new relation I, and *define* it as follows:  if and only if,
for all X, D(X, h1) implies D(X, h2), then I(h1, h2).  Such a relation
may be useful; but it's not the dependency relation D.

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

I don't understand the distinction you're trying to draw.  What
make cares about, and should care about, is the D relation.
Providing support for the user to specify the I relation might be
useful, but only as a notational shorthand:  make could derive D
relationships from the given I relationships, relieving the programmer
of the burden of enumerating those D relationships herself.  But
they're not equivalent, and treating them as such leads you into
the "touch hdr1.h" morass.

A better approach, I think, is to automate as much dependency determination
as possible.  Various makefile generators and "new makes" do this,
modulo a few snags involving conditional inclusion.  More could be done.

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

Ah, you like to live dangerously :-).  Most of the time, it's better to
do a little extra recompilation than to discover that the "bug" you've
been tearing your hair out over for the last day and a half is really
caused by an out-of-date module.

You're right, make and the makefile generators are overly conservative
in determining the D relation.  They could do better by doing syntactic
analysis of the changes to a source file.  That is probably the way of
the future for environments supporting large software projects.
Determining the minimal correct D relation is, in general,
undecidable:  if I add some code to a source file, it is undecidable
whether that code will ever be executed, hence whether the source file
needs to be recompiled.  No matter.  I think syntactic analysis will
get us close enough for practical purposes.

Jim Shankland
jas@ernie.berkeley.edu