makefile makers

[Richard Harter]

In article <59474 at aurs01.UUCP>, throop at aurs01.UUCP (Wayne Throop) writes:
> > 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.

	[... Many interesting and cogent remarks deleted ...]

> 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.

This touches on one of the many other failings of make which, in this case,
is really a failure of the underlying operating system.  Many of us, I
suppose, have been bitten by moving (mv) a source file from one directory
to another and discovering that make does not rebuild the object file in
the target directory because the source file date did not change in the
move.  One could say that the problem is that this is a bug in mv.

However the problem is really that the out-of-date check is really a
heuristic work-around for the fact that files (in most OS's and UNIX
in particular) do not have pedigrees, i.e. there is no way to determine
how a file was created.

Another common instance of this problem is the situation where the build
is parameterized.  When we build a target from an object we really need
to know both (a) has the object changed, and (b) are we using the same
build rule.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.