Or; a build system is harder than it seems.

Makefiles work fine in the trivial case, the problem is that things quickly become complex. Automating that complexity seems like it should be easy but, as it turns out, it isn't.

Is there something about the (admittedly very difficult and thankless) task of automating builds that justifies re-inventing the wagon-wheel of languages? Because that was my specific complaint, and there's a reason why it was specific.

Because it seems easy. And easy things done "wrong" require re-invention.

There should be a way to $FOO. Well, there's a way to do it in a Makefile but figuring that out is harder than should be, and doesn't make sense when you finally do figure it out.

"Well that way is stupid. Here's how I'd do it:"

CMake started for needing a suitable build system for a medical visualization application[0][1] that Kitware was working on, iiuc. How they could be using Tcl (an established, purpose built embeddable scripting/control language) in the Insight project, come to the conclusion they need a custom build system, and then when it comes to a control language decide to roll their own is a mystery to me, and a dropped ball, as far as I'm concerned.

I like cmake, and used to use it exclusively, but after running into so many issues with their homebrew scripting/configuration language, I've mostly moved on. I wouldn't be surprised if I end up coming back, and I'd encourage everybody to give it a shot (the ease of typical simple Makefile generation, but with extra muscle), but the omission of Tcl as a control/config tool has always baffled me.

  [0] http://en.wikipedia.org/wiki/CMake#History
  [1] http://en.wikipedia.org/wiki/Insight_Segmentation_and_Registration_Toolkit

edit: formatting