Recursive #includes

Doug Gwyn gwyn at smoke.BRL.MIL
Tue Feb 28 03:03:00 AEST 1989


In article <964 at philmds.UUCP> leo at philmds.UUCP (Leo de Wit) writes:
>In article <9727 at smoke.BRL.MIL> gwyn at 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.



More information about the Comp.lang.c mailing list