Re: asynchronous make(1), anyone?

[David Laight <david%l8s.co.uk@localhost>]

On Wed, Apr 11, 2012 at 07:32:11PM -0400, Matthew Mondor wrote:
> On Wed, 11 Apr 2012 17:01:34 -0500
> David Young <dyoung%pobox.com@localhost> wrote:
> 
> > 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.
Saving either :!! or <move mouse><up arrow><enter> doesn't actually
seem worth the effort.

> > One way to automate that is to run make(1) in a tight loop,
> > 
> >         while true; do
> >                 make <targets>
> >         done
> > 
> > but I think that to do that fast enough that the programmer does not
> > have to wait very often for the computer, you would have to be very
> > fast, and the computer will waste a lot of energy re-running make(1).

Not only that, but any build failure with result in a complete spewage
of output.

> > How hard would it be to make make(1) sleep until any one of its targets
> > was older than its sources, build out-of-date targets, and repeat?  This
> > may be a good application for kqueue(2)'s EVFILT_VNODE filter?
> 
> Hmm interesting idea.
> 
> As for make watching files for change, I see a few possible
> challenges:  kevent currently requires a file descriptor per file
> being watched (possibly an issue with large projects), the alternative
> being running through the files checking timestamps, like make does.

Not sure that'll work, an editor probably ought to do a 'safe write'
sequence involving temporary file and rename to avoid file lossage.
If they do, then checking the directory timestamp would be needed
instead.
I suspect most editors reopen the output file with O_TRUNC | O_CREAT
- that is certainly useful when editing on layered fs.

        David

-- 
David Laight: david%l8s.co.uk@localhost