[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: asynchronous make(1), anyone?
>>> 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
> I'm not actually that is a significant saving.
I'm inclined to agree. Especially in view of other considerations,
> Saving either :!! or <move mouse><up arrow><enter> doesn't actually
> seem worth the effort.
Or ^X^E, or whatever the gesture is. Yes.
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
Main Index |
Thread Index |