Cross-platform build generators like this are great since they give the developer a choice about what environment to use, but in this case I found that the projects it generated had several problems: namely unwieldiness (a gazillion targets in one huge XCode project) but more seriously, they were impossibly slow to actually start building.

Efficient development is all about short feedback loops - just like you don’t want to wait six months to discover the feature you just added wasn’t what was required, you also want to find out as quick as possible when you have introduce syntax error in your code.

In my opinion this is the one thing Apple got right with Xcode 4, when they integrated the clang parser right into the IDE. You’d be amazed how much less you actually hit the build button if you can already see your errors as you type.

That said: I actually try to avoid working in XCode whenever I can since it mostly sucks and is just too painful to make me productive - I prefer to use Emacs where possible. One thing I do miss though (when coding in C++ especially) is the kind of tight integration with the compiler tool-chain I mentioned before.

Turns out that Emacs does actually have an answer to this problem - it’s called flymake. Better still it seems the Google guys have been down this very road and have their own flymake Emacs module which lets it work with ninja (a new build system which focuses on speed and is now supported in GYP).

Unfortunately when I hooked this up I was disappointed: far from shortening the feedback loop flymake ran dog-slow - it took something like 12 seconds (during which Emacs blocks input) to get feedback into my Emacs buffer which was next to useless. Googling for “slow flymake” didn’t turn up anything useful - it seemed to be working for other users so I concluded it must be something about my setup that was causing the problem.

Determined to make this work I took the next logical step - stop guessing and profile the misbehaving code. Sure enough I saw almost instantly where Emacs was spending it’s time - it seemed to take forever to parse the output for errors. Odd. Next I tried to do the same myself: parse the output line-by-line to see if anything in particular was slowing it down. Bingo.

Turns out that when ninja fails a build it (logically) spits out the full command line that failed. The problem was that this line was ginormous and flymake was taking forever to run the various regexps it uses to extract errors and warnings from the build output. The good news is that this can be fixed: I just needed a way to stop Emacs bothering to parse this line since it would clearly never contain any errors or warnings itself.

Whilst I know the proper way to do this was probably to write a wrapper for the offending function and install it with advise, it was early in the morning and my elisp-foo wasn’t up to it. Instead I turned to the simple solution: a trusty shell-script.

With the help of this wrapper I finally achieved what I was after - I now have near instantaneous feedback when I introduce new build errors to my code - awesome!