A question on C programming style

Steve Summit scs at hstbme.mit.edu
Tue Apr 16 10:28:21 AEST 1991


In article <KERS.91Apr15093213 at cdollin.hpl.hp.com> kers at 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 at adam.mit.edu
                      (temporary alternate) scs at hstbme.mit.edu



More information about the Comp.lang.c mailing list