makefile makers

[Wayne Throop]

> rh at smds.UUCP (Richard Harter)
> It's a non-trivial problem -- it's really an AI type problem because you
> need some knowledge about what kinds of things you are making.

True.  Even make (and descendants) has been called "an expert system
for C programmers", with some reason.

> Given [..what-includes-what and what-invokes-what (in 3GLs)..]
> information, the make file writing is simply an exercise.
> However life is not that simple. 

Understatement if ever I heard one.  (And note, in addition to being an
"excersize", there are a lot of design decisions embodied in or
mediated by makefiles (some of which Richard alludes to, eg,
compilation switches)).

> [..problems include..] [...] external libraries [...]
> [..local code in..] libraries -- this changes the whole dependency 
> analysis problem [...]  intermediate preprocessors, e.g. lex, yacc,
> [...] data file dependencies that have to be factored in
> [...] the build may be parameterized by [...] options and parameters

Now, the library problems can be finessed (as Richard said), 
data file dependencies are simply more "expert" rules akin to those
we started out with for "knowing" about .c and .h files and "main"
and all that, and if make would only deal with non-file entities,
options and parameters can be viewed as inputs to the compilation 
(or other transform) process.

( There is also a larger problem for which options and parameters are a 
  special case, and that is different implementations of the
  same interfaces.  There is no general solution other than human 
  packaging choices here, similar to the choice of compile options
  in the subcase.  (Of course, heuristics could be applied, eg,
  to decide whether a quicksort implementation of a sort interface
  would be better than a shellshort or heapsort or whatnot, but I
  really don't see any algorithmic solution for the general case.) 
  (In fact, choosing among algorithms seems like one of those
   things that's NP complete or equivalent to the halting problem, eh?) )

This leaves us with "intermediate processors", which is also solvable
by enhancements to the make engine.  In particular, derivation of
dependencies must be a co-process and not a pre-process to the 
automated construction itself.  I think this provides a solution
to any case that is computable at all.

( Note that to perform well, interweaving derivations and "make"-like
  construction requires the construction engine to keep more information
  around in some intermediate format.  But such a scheme could be used
  to mend many deficiencies of make along with this one. )

So, I think none of the problems really standing in our way here are
fundamentally intractable.  I already have a system which essentially
solves the "intermediate processors" problem for source generation (ie,
only requires local knowledge of how to derive dependencies, and does
not need to know how to extract .c dependencies out of .y and .l
files).  Extending this to include finding closures from "main"
routines (assuming absence of (or disambiguation of) multiple
implementations of a given interface) is not prohibitive.


There is of course a lot more to the subject (for one example,
"automount"-like virtual filesystems that construct out-of-date files
when they are open(2)ed for reading), but certainly the current state
of "make" technology is anomalously primitive.

Wayne Throop       ...!mcnc!aurgate!throop