Very interesting comments from all.
In my opinion, Shake excels at a few domains.
* If you have lots of complex interdependencies, Shake lets you manage
them nicely. That's not really the case here, but is in large
heterogeneous build systems, e.g. the GHC build system.
* If you are writing things quickly, Shake lets you manage
exceptions/retries/robustness quickly. For a project which has the
effort invested that Stack does, that's less important, but for things
like MinGHC (something Stack killed), it was critically important
because no one cared enough to do all this nasty engineering.
* If you are experimenting, Shake provides a lot of pieces (resources,
parallelism, storage) that help explore the problem space without
having to do lots of work at each iteration. That might mean Shake is
more of a benefit at the start of a project than in a mature project.
FWIW, the concurrent execution stuff in the middle of Stack actually
looks fairly hairy! I see a dependency based build system, with
features like staunch mode and parallelism. It's almost certainly an
O(n^2) algorithm in several places, although I suspect n is typically
small enough. I guess it assumes topological sorting and no dead links
- but I would assume all those are guaranteed in advance. esFinalLock
gives me a gentle shiver. esInAction looks like a space leak, unless
forced by actionDo. ActionContext worries me a bit, is it meant to
list all actions that aren't this one? That seems a very weird
All those comments about Execute.hs are not intended to persuade you
to move to Shake, but I do see plenty of resemblances of Shake in
there. In many ways you have written a mini-Shake.
> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/1468257939-sup-6083%40sabre