Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.lang.c Subject: Re: A question on C programming style Message-ID: <12126@dog.ee.lbl.gov> Date: 16 Apr 91 21:03:34 GMT References: <1991Apr13.013911.18151@athena.mit.edu> <1991Apr16.002821.19233@athena.mit.edu> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 43 X-Local-Date: Tue, 16 Apr 91 14:03:34 PDT (this is drifting well off the comp.lang.c beam; followups should probably go elsewhere.) >In article kers@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@athena.mit.edu> scs@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@ee.lbl.gov