Make it easy to integrate with hobbes/FSNotify

[ndmitchell]

I should document integration with Hobbes/FSNotify, and perhaps provide a restart-aware function that kills existing builds and restarts them if something changes.

[ndmitchell]

I've had some issues with FSNotify, see haskell-fswatch/hfsnotify#50 - I should check they still occur on my Win8 machine.

[ndmitchell]

One option is just to poll all the source files. I should provide the building blocks (likely returning the source files), plus just poll mod times like I do in ghcid.

[ggreif]

Here is an idea that could reduce CPU load when polling for changed files: Keep a short list of recently changed files (popular source files the user seems to be working on) and poll these more frequently (e.g. 2Hz, to ensure high responsiveness). Do full polls only every 5 seconds or so, to reduce CPU load. Can the polling be run concurrently on several cores?

[ggreif]

Maybe the lag between change detection time and the time of starting the first dependent build recipe could be reduced by speculatively starting the build before all prerequisites are polled for changes? Then verify that the build was ok to do, or else rebuild. I am talking about 10000s of prerequisites here, for small trees I think the added algorithmic complexity is not worth it. If it just falls out of the internal architecture then all the better.

[ndmitchell]

Polling can be run concurrently on several cores, but it tends not to go any faster, since you are really measuring disk access time. For ghcid I originally started with polling and then moved to fsnotify. The result was that battery life decreased dramatically and responsiveness improved a lot. As a result, I'm not inclined to do anything with polling - it's either slow or power hungry, often both.

Starting the build first speculatively is fine, but basically amounts to polling - it's going to be very power hungry.