Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!emory!mephisto!mcnc!rti!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.lang.c Subject: Re: C + Make Summary: I hate to disagree with Chris however slightly... Message-ID: <0949@sheol.UUCP> Date: 15 Sep 90 21:01:34 GMT References: <1990Sep11.165709.24875@sj.ate.slb.com> <26549@mimsy.umd.edu> Lines: 38 > From: chris@mimsy.umd.edu (Chris Torek) > I have two recommendations, both of which were learned through experience. > 1. Put the dependency-making in a separate program. Much as I am aware of the dangers of disagreeing with somebody as usually-correct as Chris, I disagree slightly here. My experience says that packing all the dependency-making into a single step seperated from the construction step is very bad for information hiding, and makes for monolithic, hard-to-maintain, hard-to-enhance dependency "expert systems". All very well if you are doing things the way the expert system expects, but deviate or innovate, and BOOM... explosion in a damp spaghetti factory. In fact, Chris' second rule: > 2. Do not make `mkdep' edit the makefile. [.. instead ..] [...] > make -f Makefile -f .depend > [...] ... obliquely illustrates part of the problem with the first rule. The dependency occurs in a single massive step before the "real" work of construction begins. Thus, any source that is generated "on the fly" (like yacc or lex, but more complicated... for example computing a perfect hash literal array, or whatever) must be treated as a stylized special case in the dependency check. The natural way of computing the dependencies of the output files using the method of an existing subcase won't work because the files don't exist yet. Not that this problem is insoluable. I've seen it solved. It's just that the solution, while effective, seems not to have an audience. ( The basic notion of the solution is that the construction engine must construct the dependency graph on the fly... quite doable, trust me. ) -- Wayne Throop !mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org