Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!nosc!ucsd!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Recursive #includes Message-ID: <9752@smoke.BRL.MIL> Date: 1 Mar 89 05:41:35 GMT References: <9736@smoke.BRL.MIL> <2538@goofy.megatest.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 29 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. 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..