Bugs in the AT&T Toolchest program 'nmake'

[David Collier-Brown]

In article <MCGRATH.89May19190412 at paris.Berkeley.EDU> mcgrath at paris.Berkeley.EDU (Roland McGrath) writes:
[commenting on state files]
| This is nmake's main *selling point*.  Whether such incredible hairiness is
| a `virtue' is highly debatable.

In article <11564 at ulysses.homer.nj.att.com> ekrell at hector.UUCP (Eduardo Krell) writes:
| So where you're example of why this wouldn't be a "virtue"?. Depending
| on just the time stamps to decide whether a file needs to be recompiled
| or not is simply unreliable. If you still don't see why, I can provide
| you with plenty of examples.

  Not wanting to interfere unduly in a slanging match between
developers (;-)), I would like to point out that neither state files
maintained by programs nor dates maintained by the os are sufficient:

  Dates can be set inappropriately by programs modifying
non-significant parts of files (ie, comments in ordinary files, other
structures in compound files which are in some way "made").  
  State files are peculiar to the program which creates and maintains
them. If that program is make, or indeed, if it is any ordinary user
program, the file can only be updated by that program, and thereby can
end up inconsistent with external reality.

  I worked on a software development environment once which kept
dependency information in the main database, (ie, as a form of state
file), and we found that we **had** to allow the operating system to
update that information in a large number of cases, thereby adding
substantial complexity to the project.

  --dave (dates are part of an open system, and are "Gnu"ish,
	  states are formally more complete, and are "lab"ish.
	  anybody got a **good* solution?) c-b