$ cd project
$ inotifywait -m -e modify,close_write,move,move_self,create,delete,delete_self -r . | while read; do make; done
Every time any source is modified, renamed, created, etc, that will run 'make', rebuilding whatever output artifacts you need.
As long as you're careful about always re-fetching artifacts (like css files built from whatever css-sugar-y thing is hot this week) somehow, that should set you up nicely, and it generalizes to all kinds of workflows.
Thanks for making me aware of this. This is linux specific but something like this seems to be available on Mac OS X (https://github.com/alandipert/fswatch).
I don't quite understand where in your command you specify that make is executed? Could you expand on that.
the command "inotifywait -m -r . -e {some events}" recursively watches all inodes in the current directory (the "-r" and "." parts) for events in the {some events} list, and every time something happens (you save a file, create a new one, open a file, etc etc), inotifywait prints a line.
The "-m" flag makes it print a line and keep watching. Without that, it's a one-shot (which can work like [0] but all the setting up and tearing down of inotify watches is expensive on a large project).
[0]
$ while inotifywait -e some,events -r . ; do make; done
I got sick of not having a unified way of managing auto-rebuiding across the variety of tools I use (compass, coffescript, closure compiler, rake, etc) so I built something similar. I just wanted to say if * changes, run X, oh and by the way please debounce change events before running X. And the app needed to be easy for other devs to use it reliably and reproducibly.
As I typed it I was thinking that debouncing change events would be nice; as I wrote the above, you'll get several events depending on what operations you're performing.
It happens that subsequent invocations of 'make' will be blindingly fast because it will check inode timestamps (by default, you can force make to look deeper if you have Reasons) and because those inodes will still be cached "somewhere" in the kernel. So, debouncing isn't critical for this particular use case, but it would give me a warm fuzzy feeling.
Hey, I am the Sword author. Harp development and Sword development have begun almost simultaneously. You should stick with Harp if you use typical NodeJS tools for templating (like Handlebars and Stylus), and use Sword if you prefer Ruby ones.
Sword indeed looks very cool, and yes, it is almost identical to Harp.
People should really pay attention to this approach because I'm fairly confident this is where static web servers/generator are headed. By lazily compiling only the assets that are needed when requested we save a stupendous amount of cpu cycles and we can keep the development workflow much more natural and rapid. Regenerating the world as Jekyll does, is ridiculously slow, awkward (spews out static files everywhere), and still requires a static web server to serve the files.
Today many people are manually setting up pre-compiling with tools like Grunt and Make to do their pre-compiling but I don't expect this to last much longer due to the cognitive overhead of maintaining these scripts and the lack of features such as layouts and partials. Not sure if sword supports this but I couldn't imagine harp without it.
@svoroval - Best of luck with Sword. Looks like we are on the same page :)
@taylorlapeyre - FWIW SASS support in Harp is right around the corner. We held off until node-sass didn't require a compile step to be installed. It now meets that requirement.
I don't really see the benefit over using something that does background compilation e.g. CodeKit.
Also it seems a little silly/wasteful to use this in a production environment, which I may be mistaken about but the last paragraph seems to be instructions for deploying a site on top of this.
There seems to be no mention in the docs of where the compiled files end up, if anywhere; taking the docs literally it appears that this is the preferred way to use sword, which is indeed silly and wasteful.
It might mean production but that paragraph is useful for dev server configuration. I'd want --daemonize almost all the time in a dev environment. --compress sounds useful for exporting assets for production.
Suppose I want to look at a CSS file (zzz.css, say). But that file does not exist, since I'm using LESS to make my CSS. The LESS source exists; the CSS output does not -- yet. I'm using sword.
I have a Unix command prompt in front of me. What do I type?
As long as you're careful about always re-fetching artifacts (like css files built from whatever css-sugar-y thing is hot this week) somehow, that should set you up nicely, and it generalizes to all kinds of workflows.