Recursive #includes

[Daniel F. Fisher]

In article <9752 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
writes:
>                     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).

Gack!! If a makefile touch(1)es a .h, it may cause a program that uses
a different set of -D, -I and -U options in to be unnecessarily recompiled.
As Doug says, "No action is required," so none should be taken.  It is quite
possible to arrange for make to know about the exact header file dependencies
of a given object file (compiled with a particular set of -D, -I and -U
options).  If the same source file is compiled using other options, it should
result in a different object file, with a different set of dependencies.
In System V, the -H compiler option will cause cpp to list one stdout or
stderr (I forget which), the pathnames of the include files it visits.  In
BSD, the -M compiler option will actually generate make dependencies on
stdout.  These features can be used in a shell script with awk and/or sed to
build a very nice make dependency generator.  It can be called for each object
file that is a target of the Makefile in a depend target within the makefile.
Make programs with the .INIT and include features can actually automatically
rerun make depend before evaluating other targets or including the
automatically generated make dependencies if the makefile is changed.  Make
depend can be rerun manually if #include lines are changed in relevant .c
or .h files.  If no automatic way is possible, manually generating these
dependencies, though painful, will suffice.  In my experience, generating
the dependencies, even manually, pays of in the long run.

-- 
Daniel F. Fisher
dff at morgan.com