Re: asynchronous make(1), anyone?

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

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.
> 
> 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).
> 
> 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.
Also, it's not uncommon for the build system of a project to invoke the
build system of another...  Since it's make, it theoretically would be
possible to only rebuild the modified file(s) immediately and their
dependencies, without running through the dependency tree from the
beginning, possibly with some extra work.  Otherwise make would be
redoing the full checks anyway.

I guess that an alternative would be an editor plugin that's coupled
enough with make, to immediately invoke a minimal make target for a
module that was just saved...  This could avoid using too many file
descriptors, and give to make a hint on what piece to build, to avoid
scanning the whole tree...

Not totally on topic, but alternatives related to fast development:
this reminds me that Lisp can recompile a single function in the
interactively running image.  ECL compiles to C, so to achieve this it
uses DLFCN(3) with custom init/cleanup hooks.  If then again your IDE
is coupled closely enough to your project, using dynamic modules like
this would be an alternative, as a single module needs to be
recompiled, leaving the linking for runtime, as long as the
project-mandated-ABI is maintained.  The editor/IDE could then HUP a
daemon to reload the updated modules, etc.  Of course, a shell with
separately-built set of commands is another similar type of fast
modular development...
-- 
Matt