Re: CONS specs update?

"H. S. Teoh" <[email protected]> writes:

> I'm not sure how to generalize this, but there might be a way to
> specify that xyz.c must be re-scanned every time it's re-generated,
> and there may be more than one scanner (e.g., if P1, P2, P3 must be
> run, in that sequence, on the file to transform it to the desired
> output).

What if P1 or P2 fails and leaves a corrupted file ? 

How Cons can deal with this failure when the user re-runs the build
command ?

> (I realize that allowing self-references could potentially require
> pathological code which may be a pain to test; this is why I suggested
> that we should treat every step as having distinct input/output. It
> does make things a lot easier to implement, and less prone to
> pathological hard-to-debug cases.)

Agreed. Reviving cons will be hard enough without considering
self-reference in the dependancy graph.

So I'd suggest to first have a new cons without the current drawback
then _consider_ fancy features.
 
Cheers

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner


_______________________________________________
[email protected]
http://lists.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/