Re: asynchronous make(1), anyone?

["James K. Lowden" <jklowden%schemamania.org@localhost>]

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.  

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.  

Could anyone explain to me why this isn't implemented in the
filesystem?  ISTM that the problem of "notify userspace when something
changes in this part of the filesystem" is fairly general, and that
FIFOs are an obvious way to move event information from kernel to
userspace.  

--jkl