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