C + Make

Wayne Throop throopw at sheol.UUCP
Sun Sep 16 07:01:34 AEST 1990


> From: chris at 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 <original args>
> [...]

... 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 <backbone>!mcnc!rti!sheol!throopw or sheol!throopw at rti.rti.org



More information about the Comp.lang.c mailing list