Re: asynchronous make(1), anyone?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Furthermore, suddenly the programmer has to be careful about order
>> of saves in some cases, such as when editing the build machinery
>> [...]
> If the programmer has to be careful about order of saves, then it's
> not a robust solution.

Right.

I don't think this is fixable, though, at least in some cases.  Getting
it right depends on information not accessible to make, in some cases
probably not accessible to anything outside the programmer's mind, as
in "I intend to update that but haven't yet, and, until I do, doing a
build with the new version of this file will destroy $THING".

There's always the "don't do that, then" answer, to say that people
working with such setups simply shouldn't use this facility.  I'm not
sure to what extent I think that's a reasonable response.

The only way I can see to make this entirely safe would be to do it
purely speculatively.  Something like doing the build in a dedicated
union mount, with the results pushed from the upper layer to the lower
only when a human says to - it wouldn't be quite that simple; I'm
handwaving here.  It wouldn't eliminate all the human effort, but it
would mean that most/all of the slow work is already done by the time
the human decides to pull the trigger.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B