Recursive #includes

[Stephen 2. Williams]

In article <2538 at goofy.megatest.UUCP> djones at megatest.UUCP (Dave Jones) writes:
>From article <9736 at smoke.BRL.MIL>, by gwyn at smoke.BRL.MIL (Doug Gwyn ):
>> 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 INCORRECT.
>
>
>By what rationale can the first .h be said to depend on the second?
>How is _make_ to "do something to construct the target", if not check
>it out of SCCS or RCS?  And if it does that, what has the second .h
>got to do with the price of beans in Slobovia?

Consider the following stunt (I used it in a longish project of mine):

	prog: a.o b.o c.o
		cc -o prog  a.o b.o c.o

	a.o: master.h

	master.h: sub1.h sub2.h
		@touch master.h

Notice that the master.h file is created from the two files sub1.h
and sub2.h, presumably because of nested includes.  Some might gripe
that you are doing work where none is necessary, but it works quite
well.  *Technically* speaking, Dave is correct is saying that nested
dependencies cannot be directly represented, but make is apparently
general enough for a programmed solution.


>
>He's gotcha, Doug.  Say, "Uncle."


Say no such thing, Doug:-)



Steve 2. Williams	(steve%crown%journey%attmail at research.att.com)