Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!olivea!mintaka!bloom-picayune.mit.edu!news
From: scs@hstbme.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: A question on C programming style
Summary: nested #includes, Makefile maintenance
Message-ID: <1991Apr16.002821.19233@athena.mit.edu>
Date: 16 Apr 91 00:28:21 GMT
References: <1991Apr13.013911.18151@athena.mit.edu> <KERS.91Apr15093213@cdollin.hpl.hp.com>
Sender: news@athena.mit.edu (News system)
Reply-To: scs@adam.mit.edu
Organization: Thermal Technologies, Cambridge, MA
Lines: 45

In article <KERS.91Apr15093213@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>Steve Summit says [apropos the Nexted Include discussion]:
>   ... Manual Makefile
>   maintenance quickly becomes nearly impossible...
>
>Why does manual makefile maintainance ``become nearly impossible'' (presuming
>that it wasn't already)? I handle this particular problem by having entries
>for each .h file, treating the includes as ``dependencies'', with a ``touch''
>command as the action: thus, if foo.h includes bar.h and baz.h, I have
>
>    foo.h: bar.h baz.h
>	touch foo.h

I'm a stickler for meaningful modification times (I want the
modification time to reflect the last time *I* modified the
file), so I can't use this trick.  The names of all the
(recursively #included) header files appear on the object file
dependency line:

	a.o: a.c b.h c.h

if a.c #includes b.h, and b.h #includes c.h .

Strictly speaking, this is a more "correct" makefile, since b.h
doesn't really "depend" on c.h in the sense of "has to be rebuilt
if c.h changes."  (This is, to be sure, a debatable point, and
often is.  I believe the make documentation recommends the latter
interpretation, however.)

I gather that the "touch" trick is fairly widely used, so I
suppose it must work, but I can't say if it has any real
practical drawbacks (other than losing the "real" modification
time, and the philosophical objections).

"Impossible" is, of course, a relative term in this field.
I'm profoundly lazy, and I refuse to keep even simple Makefile
dependencies up-to-date manually, let alone complicated ones
which require chasing through several levels of #inclusion.
That's why I use an automatic dependency generator.  (For me,
doing so has no disadvantages, because I wrote my own that
behaves just as I expect it to.)

                                            Steve Summit
                                            scs@adam.mit.edu
                      (temporary alternate) scs@hstbme.mit.edu