[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: asynchronous make(1), anyone?
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
> > 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
I suspect most editors reopen the output file with O_TRUNC | O_CREAT
- that is certainly useful when editing on layered fs.
David Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |