Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!labrea!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Recursive #includes
Keywords: recursive includes, modularity
Message-ID: <9736@smoke.BRL.MIL>
Date: 27 Feb 89 17:03:00 GMT
References: <570@marob.MASA.COM> <9727@smoke.BRL.MIL> <964@philmds.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <964@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
>In article <9727@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>|It's easy to get the Makefile correct; just declare that a header
>|depends on the others that it #includes.
>This is not correct, as it is never correct to declare make dependencies
>between source files (this includes header files as well).

Sorry, but it IS technically correct.  Dependence is a transitive
property.  The only practical problem you could run into here occurs
when your version of "make" barfs on cyclic dependencies caused by
mutually-dependent headers.  If you don't have recursion among the
headers, though, you should be safe.

"make" has an inherent design problem in that it doesn't properly
distinguish between logical and physical dependencies.  That can
indeed cause some strange behavior and is responsible for the "FRC"
kludge one often sees in fancier makefiles.

The make/SCCS behavior you describe is clearly erroneous; a later-
modified checked-out file should never be clobbered by retrieval
from the archive.  I think this behavior occurs because of the
redundancy introduced in the default rules in an attempt to
compensate for "make" not getting the logical transitivity right.