I’m in the process of moving from the tup build system to Haskell Shake and I’m looking for guidance on making it rebuild projects whenever files are modified.
I would like my build system to automatically notice when files change and start rebuilding right away without needing to do it manually. Although I could go for external solutions such as inotify or file watcher programs, my main interest lies in using the twitch library since it aligns well with the Haskell language.
The twitch package appears to be a great option due to its use of a similar do notation syntax, but I find the documentation to be quite sparse. I’m struggling to figure out how to effectively link Shake’s build rules with twitch’s file watching features.
Ultimately, I want to use pandoc to work with documents in various formats and have them automatically output in multiple formats as source files are edited. The previous system I had didn’t handle build targets properly, which led to my transition to Shake.
Has anyone out there managed to merge these tools successfully? What would be the most effective way to configure automatic rebuilds?
Hit the same issue six months back when switching my docs pipeline. Skip the twitch integration headache - just use Shake’s --live flag with a simple wrapper script. Create a main function that loops your Shake build rules with file system monitoring. I set up a custom Rules monad that checks file timestamps and triggers rebuilds. Just spawn a monitoring thread to watch your source dirs and signal Shake restarts when files change. For pandoc stuff, structure your Shake rules with explicit need statements for all input dependencies. This keeps dependency tracking solid when files update. Bottom line: let Shake handle dependencies, use your monitoring layer to trigger rebuilds on filesystem events.
Honestly, all this manual Shake integration is overkill. I’ve built similar document pipelines - the real problem isn’t your build system, it’s managing all the moving parts.
Skip wrestling with twitch or writing custom file watchers. Just automate the whole thing properly. Set up a workflow that monitors your source files and triggers pandoc conversions automatically. No need to hack Shake into doing something it wasn’t designed for.
I handle this exact scenario with automated pipelines that watch file changes, process documents through pandoc, and output multiple formats without manual intervention. The key is having proper automation that handles file monitoring, dependency tracking, and build orchestration in one place.
Your pandoc conversions will be faster and more reliable when you’re not forcing a build system to be a file watcher. Plus you get better error handling and can easily extend it for more complex document processing later.
the shake-watch combo’s tricky but totally doable. I switched to watchman instead of twitch - way more reliable. Just run shake in a subprocess and restart it when watchman catches file changes. throw system "shake mybuild" in your watch handler and you’re good. make sure your shake rules have proper file dependencies set up though, or you’ll get weird rebuild issues.
Been wrestling with this exact setup for my thesis too. Here’s what worked: use Shake’s built-in file monitoring through shakeOptions with custom polling intervals. Set shakeTimings and shakeVerbosity to see what’s happening, then wrap your main build in a monitoring loop that checks modification times. The trick is letting Shake handle the dependency graph while your wrapper just restarts builds. I made a simple polling setup that compares file modification times to a stored baseline and kicks off fresh Shake runs when things change. For pandoc workflows, make sure your Shake rules use getDirectoryFiles patterns to grab all source dependencies upfront. This keeps you in Haskell’s ecosystem without external libraries. Rebuilds stay fast since Shake only rebuilds what changed, not everything.
Had this exact issue last year during a big documentation project. Skip the twitch integration headache - Shake’s shakeRebuild with basic file monitoring works way better. Run your build script continuously using forever from Control.Monad and wrap your main Shake action in try-catch. Use System.FSNotify to watch source directories and keep a shared IORef timestamp that updates when files change. Your Shake rules just check this timestamp and rebuild when it’s different. The trick is setting up pandoc rules with proper getDirectoryFiles calls so Shake knows all dependencies from the start. You get automatic rebuilds without wrestling external libraries into Shake’s execution model. Performance stayed good even with huge document sets since Shake handles dependency checking efficiently.