[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: prerequisite staleness criteria

From: Paul D. Smith
Subject: Re: prerequisite staleness criteria
Date: Mon, 17 Apr 2006 22:22:29 -0400

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

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:            
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

reply via email to

[Prev in Thread] Current Thread [Next in Thread]