Recursive #includes

[Wayne A. Throop]

> dff at Morgan.COM (Daniel F. Fisher)
> 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).

Not quite so easy when considered in full generality.  Fairly easy if
one wants to suppose that all include dependencies are known from
sources.  Quite a bit harder if one wants to cope with .c or include
files generated on the fly.  In such cases, the only fully general way
to do it is to have the compiler (where compiler subsumes
"preprocessor") co-operate co-routine-wise with the automated
construction system, and ask for (for example) each include file to be
constructed (if necessary) exactly when the compiler decides to open
it.

> Make depend can be rerun
> manually if #include lines are changed in relevant .c or .h files.

I much MUCH druther it be run automatically.  And it can be.  Since
around here we generate .c and .h files by various arcane processes
(and not just well-known ones like LEX and YACC), I prefer to have
include dependency tracking fully automated and capable of handling as
many cases of generated files as possible.

I haven't yet gotten compilers to co-operate in the above noted
fashion.  Until then, the tradeoff I make is to suppose that an
#include is going to be tread upon.  This makes for a rather small (in
my experience) tendency to compile modules that "don't need it".  But
having the whole thing automated in such a way that I don't need to
think about it and which is safe is a blessing well worth this
particular trade (IMHO).

Of course, people with different circumstances may well reasonably
choose other tradeoffs.

--
"A" is for Atom, they are all so small,
That we have not really seen any at all.
"B" is for Bomb.  They are much bigger.
So mister, you better keep off of the trigger.
         --- Edward Teller (in an interview on Nova)
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw