I suggest to read more about Shake before dismissing it. The paper is short and easy to follow. Shake solves real world problems that go ignored in other systems. If needed, one could add a simple mode via an EDSL, but so far nobody using Shake has requested such a things from what I can tell, but Neil would be better equipped to answer that. I haven't written a single Shakefile with unicode, and no you don't have to, but apparently you can, if you prefer to.

As a start I'd suggest to read "Shake before building".

I did read all of that. To me, the system seems inferior to tup, which they discuss (tup doesn't require me to specify dependencies, which I consider a killer feature). Also, tup works on windows, while that paper suggests Shake doesn't.

I didn't try tup, but I found the way it's said to detect dependencies by monitoring stuff to be a bad idea, though this is probably my personal preference. Can't tell how many developers don't like that design aspect.

Shake should work on Windows, given that Neil wrote a Windows progress bar tool for Shake.

If you don't like auto-tracking dependencies, then tup certainly isn't for you.

For me, it is a killer feature -- any system where dependencies are maintained manually inevitably gets out of sync with the code. Some systems have special compiler hacks (like gcc's -MM flag), but you still have to find the magic option for each program you use, and link them into your compiler. That's also very hard to do in dynamic languages, where you don't know what libraries you have loaded until you've run the program.

> If you don't like auto-tracking dependencies, then tup certainly isn't for you.

I do use auto-generated/-detected deps for build time dependency graphs, but I didn't like how tup implements it.

It's not just written in Haskell, it is Haskell. Your "Shakefile" is a Haskell source file. You understand the syntax if you understand Haskell syntax, and vice versa.

And no, you don't have to write Unicode arrows. You write those things as ->. For some reason academic Haskell papers use Unicode symbols where real Haskell uses ASCII.

Build systems are a good case for a domain-specific language that just knows about how to build things. Make may not always be the right DSL.

"Here's a Haskell library, go write your own build system in Haskell" is technically a solution to every build problem, but not a very practical one. Especially because Haskell libraries are themselves so hard to build on a fresh system!

Haskell libraries as well-maintained as Shake should not be hard to build on a fresh system (especially nowadays with Stack). Getting GHC onto a fresh system might be difficult if your package manager doesn't provide it.

Build systems and functional programming languages are a good match, because of the way dependencies work. Therefore, I give this tool a good chance of being succesful (though I'm not sure if/how they will win over the non-Haskell crowds). At a first glance, this paper seems very interesting. This is certainly not "yet another" build system.

> my users probably don't have the CMake 2.8.9.2 that I wrote my build script for

cmake is "pretty good" about exposing policy flags to control compatibility.

From considerable experience of building unixy packages, I wouldn't use "cmake" and "pretty good" together :-(.

Fedora EPEL6 has had to include two new cmake versions so far to be able to build more packages.

The unicode arrow is just a pretty-printed ->

The bizarre opeators seem to be an attempt to maintain similarity to make's cryptic oerstorsr