%% David Boyce <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
