Re: asynchronous make(1), anyone?

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

> Your proposal is that the compiler should immediately start building
> anything I save, but somehow it has to avoid choking or distracting
> me if it reads a half-written save file, or if I've made linked
> changes to a number of files and save them in the wrong order, or if
> I've simply saved something out of the editor that's uncompilable
> because I'm not done hacking on it yet.

I think you've missed some important aspects.

Choking is not an issue.  If it chokes, a restart once the rest of the
changes have been saved will deal with it nicely.

Distracting is an issue only if failures are actively reported to the
user without the user expressing interest in them.  I've been assuming
that's not done; there's certainly no reason it has to be done.

Uncompilable partly-done changes are just a particular kind of choking.

The hard cases are the ones where the build machinery at the time of
the save overwrites something that is not yet discardable because other
changes haven't been saved yet.  For example, let's suppose I have
foo.c which does something.  Then I decide to generate foo.c
mechanically based on some input file.  So I build a gen-foo script,
change the Makefile to use it, and save ("save early, save often"), my
next step being to go through the existing foo.c and, based on it,
build the proper input file for gen-foo.

But the build triggers and foo.c gets overwritten with whatever gen-foo
produces when it doesn't have an input file - probably nothing useful,
whatever it is - because I didn't build the input file before saving
the Makefile and gen-foo changes.

> It seems to me that there's inherently a *PONY HAPPENS* step required
> in the middle there.

Not quite.  It is conceptually possible to get this right.  It needs at
least one thing I don't think we have yet, but it's something that I'm
quite certain could be done, even if it might be rather difficult
within our current framework.

What it needs is the ability to do something like a union mount, but
visible only to a particular process and its children.  Then the build
runs in the union mount; if it succeeds, then the user has the option
of pushing everything from the union mount to the underlying space
("commit", let's call this); if it fails, even if it goes wild and
destroys all my sources, it destroys them only in the upper layer, an
upper layer that gets discarded and a new one created when the next
speculative build starts.

I'm not sure this would save much.  It would save the effort of typing
^X^E, or doing windowswitch-uparrow-enter, or whatever the gesture to
do a build is.  It would save the time required to do that.  But there
are only a few cases where it'll save much more, mostly where the user
saves files, thinks, and eventually decides to do a build without
saving anything more.

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