A question on C programming style

[Chris Torek]

(this is drifting well off the comp.lang.c beam; followups should probably
go elsewhere.)

>In article <KERS.91Apr15093213 at cdollin.hpl.hp.com> kers at hplb.hpl.hp.com
>(Chris Dollin) writes:
>>I handle [nested includes] by having [makefile] entries for each .h
>>file, treating the includes as ``dependencies'', with a ``touch''
>>command as the action ... [so why not use this technique?]

In article <1991Apr16.002821.19233 at athena.mit.edu> scs at adam.mit.edu writes:
>I'm a stickler for meaningful modification times ... so I can't use
>this trick. ... Strictly speaking, ... b.h doesn't really "depend" on
>c.h in the sense of "has to be rebuilt if c.h changes."

The latter is true but almost irrelevant (the difference between `c.h
has changed, therefore everything that uses b.h-which-uses-c.h must
change' and `c.h has changed, therefore b.h has changed, therefore
everything that uses b.h must change' is slim).  The former point is
actually more relevant.  In particular, the `touch' trick does not work
well with source code version control systems, which often either
depend on modification times or (more likely) keep files read-only
unless they are specifically being `changed'.

You can solve the latter problem by making b.h be, not just a source,
but a source-and-object: instead of including b.h, include b.i, and
build b.i by copying b.h.  Then b.i depends on b.h and may also depend
on c.h; b.i is not under source control (being an object), and files
that `use b.h-which-uses-c.h' depend on (and use) b.i.  This introduces
a new set of problems.  The best solution is to avoid intermediaries
and use real dependencies.  With a little help from the compiler, the
whole system can be automated; `mkdep' and company are a step in the
right direction, and are a sufficient solution when used with care.

(The compiler is the best place to compute dependency relations because
only the compiler knows for certain just what information the compiler
used to put together the object file.  In a perfect system one would
list only the commands used to build a program, and the system would
infer all the rest.  Perfect systems are hard to come by, and most
attempts have been rather slow; mkdep and `manually automatic'
dependencies are a good compromise, for now.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov