Re: asynchronous make(1), anyone?

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

>>> You can save a programmer who is in an edit-compile-test loop some
>>> effort at the keyboard if, as soon as they write a new version of
>>> some source file, the computer automatically recompiles their
>>> program.
> I'm not actually that is a significant saving.

I'm inclined to agree.  Especially in view of other considerations,
below.

> Saving either :!! or <move mouse><up arrow><enter> doesn't actually
> seem worth the effort.

Or ^X^E, or whatever the gesture is.  Yes.

But also...

If the make run doesn't take significant time, then you're not really
saving much.  If the make run _does_ take significant time, then
there's a problem:

        - save changes to file A
                - make run starts
        - save related changes to file B

Now, is the make daemon supposed to notice this and kill the first
make, or do we have to wait for the first make to finish before
starting a second?

Furthermore, suddenly the programmer has to be careful about order of
saves in some cases, such as when editing the build machinery (in
simple cases this means the Makefile; in other cases it can mean
scripts and such - saving such an edit half-done can lead to
spectacular lossage, sometimes even including losing source files).

> Not sure that'll work, an editor probably ought to do a 'safe write'
> sequence involving temporary file and rename to avoid file lossage.

That's another point - the make could start partway through a
non-atomic operation like saving a large file.  We aren't going to be
able to compel all editors to use writes to a temp file plus renames,
nor should we - if the source file is hardlinked elsewhere you probably
do not want to do that anyway.

/~\ 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