Re: asynchronous make(1), anyone?

[Eric Radman <ericshane%eradman.com@localhost>]

On Sat, Apr 14, 2012 at 12:09:06AM -0400, James K. Lowden wrote:
> On Wed, 11 Apr 2012 20:15:00 -0500
> Eric Radman <ericshane%eradman.com@localhost> wrote:
> 
> > Yes, I've been looking for such a tool for some time, and finally
> > wrote such utility 
> 
> Nice.  I have a suggestion to simplify it.  
> 
> Small Tools theory suggests two distinct concerns:
> 
> 1.  detecting an event
> 2.  acting on the event
> 
> If your entr(1) simply wrote the name of the changed file to a FIFO, it
> wouldn't need to control a child process.  Pretend:
> 
>       $ intr -d $HOME/project -f $HOME/project/notify &
>       $ grep \.c$ $HOME/project/notify | \
>         while read F 
>         do
>               make $(basename $F .c).o
>         done
> 
> It could be expanded to monitor anything recognized by kqueue.  

This is a more general facility, and has the nice property of giving the
shell script the name of each file that changed. I'm a little surprised
that this kind of a tool isn't in base. It's possible to write this kind
of a loop in Linux using inotify-tools, although their interface is
cumbersome.

> What happens if 1000 files suddenly appear?  I assume the shell won't
> empty the FIFO as fast as intr can respond to kqueue.  If the queue is
> exhausted, the above has the good property (to my mind) of being
> self-limiting.  

This is somewhat different than what entr is trying to accomplish.
Namely, I don't want to respond to every file change event. As an
example, it's not uncommon for version control software to update a
large set of files when they're submitted, but we don't want to run the
utility one for each file that is modified. To combat this entr ignores
events until the test runner or build program returns.

Eric