The Manual[0] contains an intro that isn't particularly compelling. It contains things like:

   phony "clean" $ do
        putNormal "Cleaning files in _build"
        removeFilesAfter "_build" ["//*"]

Which would be the make equivalent:

  clean:
    rm _build/*

Now that's obviously the trivial example. But its not trivial to drop make entirely for something entirely different. A make solution can slowly get more complicated over time. It looks like shake might be useful for something really big. I can't quite tell where the investment of learning a new tool and re-develop something(that works well enough) would pay off.

0: https://github.com/ndmitchell/shake/blob/master/docs/Manual....

Yes, but that 'make clean' will stop working if there happens to be a file named 'clean' in the directory. You need to mark clean as a .PHONY target.

Make is complicated. By the time you get all *.c files to rebuild based upon a change to any header they include, your makefile is going to look like a magic spell. And it only gets worse from there if you're doing any code generation. Make is concise, but it's weird and painful.

I've not actually tried shake, but it looks a lot less magical. I'm willing to type a little more if it means I can actually understand it when I look at it again tomorrow. Or, that my coworkers can understand me today.

Though, on an open-source project I'd probably use CMake just for ubiquity. It has the added bonus of being able to spit out either makefiles or ninja build files (which can be used by shake).

So as someone thats recently been getting into Haskell I can say this, that example while sure its rather much more verbose for the simple case, the more complex stuff is where it starts to shine more.

That and without knowing haskell a little a lot of that will look like needless chatter. But like rake once you realize the dsl is just Haskell it starts to fall into place more.

Which is fine if you're using Haskell. I'm not sure I see the case for something like this if you're not using Haskell. Adding another package management system (cabal) into the mix seems like a lot of work.

Of course I don't think language-agnostic build systems in general make a whole lot of sense unless you have a huge enough project to have a team dedicated to the build system.

In my case, I was entirely unaware of Shake's existence. The no-nonsense support for file oriented workflows is the most compelling feature of Makefiles for me.

In that regard, Shake seems really compelling. It supports the file oriented nature of my build system. It's backed by an actual programming language, with lexical scoping, functions, a module system... all the things that suck about Makefiles.

Most importantly, it solves the one thing that drives me up the wall with Makefiles: supporting custom command line arguments sanely. I detest typing `make web TARGET=prod` and `shakeArgsWith` seems like it provides the flexibility of specifying targets and flags from custom command line arguments.

Thanks for this, I'm going to try and convert a few non trivial Makefiles to Shake. Any cons I should be aware of?

For me, it always was more about infrastructure - successfully distributing a project when it's built with something less-than-mainstream is a problem, even if majority of install base is Ubuntu systems.

In this particular case, we would need to either build GHC from source for every user, or provide a binary compiled version for every Ubuntu version to keep providing source-level access to build system.