Re: prerequisite staleness criteria

[Paul D. Smith]

%% David Boyce <address@hidden> writes:

  db> Back on the original question, I toyed with delving into this a
  db> couple of years ago but then got too busy. My take is that though
  db> Paul is right of course about the complexities of persistence, GNU
  db> make should deal with it by refusing to deal with it. It seems to
  db> me that from make's point of view the task is simply to refactor
  db> the code such that all "staleness" determinations are made by a
  db> single discriminator function rather than a bunch of stat() calls
  db> scattered about as now.

Sure, this is definitely the right idea.  In fact my thinking was that
this function could even be hookable via Guile (once we integrate Guile
support) so that you could write a Guile function to do the out-of-date
computation.

Nevertheless, I would prefer that GNU make provide some kind of stateful
implementation as part of the distribution, as a proof of concept at the
very least.  And, that implementation would need to be reliable and
robust in all different setups.  One can easily imagine that the
predefined environment would be the most commonly used.


You're right, though, David; the first step is unquestionably detangling
the current implementation so that the default timestamp-based operation
is abstracted from the rest of the code.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist