[darcs-users] make continuous

[Petr Rockai]

twb at cybersource.com.au (Trent W. Buck) writes:

> twkm> changing gmake so it is a daemon that waits for events from the
> twkm> o/s would limit its portability, but i wouldn't doubt they'd
> twkm> consider doing it if it sounded cool enough.
> twkm>
> twkm> foo.c is too complex, you create bar.c, notified-gmake spits at
> twkm> you because it doesn't know crap about it yet, pull stuff out of
> twkm> foo.c, app no longer compiles or links because bar.c hasn't be
> twkm> written yet, ...  but yeah, eventually all would be well.
> twkm>
> twkm> dnotify -MCDR $(find . -type d) -e make &
> twkm>
> twkm> dnotify can't handle a directory named -e, and that particular
> twkm> command can't handle directories with whitespace in their names,
> twkm> but otherwise it would thrash when almost anything was changed.
This works:

dnotify -MCDR -q 1 -r src -e cabal build

however, this also comes at a cost: if your editor creates temporary files,
these will trigger (needless) rebuilds.

This seems to work better:

while true; do
    inotifywait -e CLOSE_WRITE -e MOVE_SELF $(DARCS_FILES)
    cabal build
done

but will miss changes done while cabal build is running... probably a more
involved program is needed to make things work correctly for all the cases. See
also http://hackage.haskell.org/package/hinotify

There are some issues with inotify, specifically if you (vim will do this)
moves a file over a watched one, you get notified, but further monitoring is
then cancelled. I imagine you need something like

watch file action = addWatch inotify [MoveSelf, CloseWrite] file handle
 where handle ev = case ev of
    Ignored -> watch file action >> action
    _ -> action

use like: watch "src/darcs.hs" (putStrLn "modified!")

It'd be great if someone wanted to build a notifier around the above "watch"
primitive, that'd sorta work like dnotify -q 1, but only waiting for specific
files.

Of course it would be also possible to build something like this with polling
(which would be much more portable, although less efficient). It would also be
possible to use forkIO to make the interface very similar to the above. By
using a primitive like "buildOrQueue" (itself exploiting IORefs), it would be
quite straightforward to implement a full build-upon-modification tool that
could invoke anything you wanted (e.g. cabal build).

Yours,
   Petr.

PS: Yes, I hope someone will pick it up from here.