I really hated the language you use to describe build tasks. It is a very frustrating mix of declarative and imperative syntax. And of course, who wouldn't want to write code in XML?! (XML, the markup language, the one we use for marking up information like documents and records.)
I was doing fairly complicated tasks with it years ago, and it's just one of those technologies that feels like it is fighting you at every turn. This was for continuous integration stuff and developer-productivity tools, not "open up Visual Studio and click the button". Thankfully much of that has been obviated over the years by things like NuGet and Octopus coming around.
> I really hated the language you use to describe build tasks.
Yup. For some reason that escapes rationality, MS chose to control the build through Workflow Foundation. And they build a horribly complicated WF "script". Pretty much universally hated.
But you may be pleased to know that they have now abandoned that, and each build task can now be described pretty much by the scripting language of your choosing.
Ah, that is nice. .NET seems to have a wonderful property where even if they start out with something dumb, they eventually come to their senses and do the right thing. Sure can take a while to get there, though.
cmake is certainly worth looking at. Doesn't take much to get up and running with it, it's pretty straightforward to use once you're set up, it takes out-of-source builds seriously, and it's got fair support for adding custom build tools (something you'll have a devil of a time getting working nicely in Visual Studio). Reasonable ecosystem as well, with a good supply of online examples and drop-in helper scripts for locating common libraries. (Compare and contrast to, e.g., MSBuild, boost jam, or JamPlus - all of which, even MSBuild, might as well by comparison have about 0 users each.)
Not to say that it isn't awful in many respects, though. It often feels as if it has been designed by 3 people, none of whom talk to one another, and all of whom have different ideas about how things should work. For every time there's some easy setting that nicely handles every platform for you there's another where you have to carefully distinguish between VC++/gcc/clang/etc. and add compiler-specific flags to some random string. And the scripting "language" is unhinged.
Still - compared to a normal project that targets N platforms, where you might well have to deal with N build systems, all appalling, if you use cmake, you'll only have to deal with one.
I was doing fairly complicated tasks with it years ago, and it's just one of those technologies that feels like it is fighting you at every turn. This was for continuous integration stuff and developer-productivity tools, not "open up Visual Studio and click the button". Thankfully much of that has been obviated over the years by things like NuGet and Octopus coming around.