Yeah; I've had to deal with MSBuild, and I've never really liked it. I have to assume that the big motivation was that they'd prefer to port MSBuild to OS X and Linux than to port MS solution files and MS project files to CMake, Automake, or some other build system.
I haven't gotten past the point of where I just hit Ctrl-F5 and Visual Studio builds stuff for me with MSBuild, so I am certainly no expert on it. But I never had the impression that people liked CMake or Automake either. I ask this not as a rhetorical question but as an actual one: are there build systems that aren't hated, or does everyone just hate the one they have to use the most?
Building using a keyboard shortcut from within an IDE is just one of the many tasks a build system is required for. Another is setting up a build server that builds the projects on every checkin, deploys it on the various test servers and runs all the test suites. That requires the build system to be scriptable, idempotent (as in weird stale cache issues won't screw up your builds) and easily controllable from the command line.
MSBuild completely sucks at these tasks when compared to any free software build system such as Ant, Automake, CMake, WAF or dozens others. It was designed to be used in conjuction with Visual Studio and you very much feel the limitations of it when you try to use it from the outside.
Everybody hates some aspects of some of them, in my experience. People also tend to have strongly held preferences in the build system department - it's a bit like text editors. I tend to view it as problem-dependent as to which system is better. If you're all java, you probably want a build tool designed for that language (for example.) Lisp has asdf and friends. My focus (cross platform C/C++ building) has led me to deal with autotools and CMake. I prefer CMake for 3 major reasons: 1) self contained - you just install CMake itself and you can handle all sorts of things (tar.bz2 decompression, file copying, directory creation, etc.) automatically and portably. No need to first install Python or Perl or... whatever for Windows. From a Linux/*BSD perspective, developing on Windows is like crossing the Sahara - you need to carry your own supplies. CMake packs a lot into a small, self contained package. 2) Learn one language and you're done. Would it have been better to go with something like lua? Probably, in hindsight (my opinion). However, compared to the mind bending complexity that is sh + m4 + automake + autoconf + ... CMake is (in my experience) quite a lot easier to get a handle on. 3) Wide support for many platforms/tools (Visual Studio, Xcode, ninja, make, Eclipse, etc.) from one common set of build definitions. The maintenance savings really add up if you need to support all those tools - Hunt and Thomas's DRY principle in action.
I'm a fan of CMake for C++ as well, but have also worked on projects that included C++, C++/CLI, and C# and unfortunately CMake support for .NET projects is close to non-existent (there is some, but it's woefully inadequate). I managed to get it to work, but in a very non CMake way (basically generating the .csproj files by replacing variables within the XML with the appropriate value).
As for MSBuild and VS - I thought that Visual Studio actually compiles things with devenv.exe, rather than MSBuild. I remember working on a project where I was trying to set up Jenkins CI to build our projects and MSBuild wouldn't work (because the environment wasn't set up correctly), but using devenv.exe instead worked perfectly.
The CMake language is just an atrocious mess, but that gets easier with time. The main problem with CMake on Windows is that it is really really slow for large projects (because it has to call back out to CMake to do all sorts of basic stuff) and that debugging CMake errors is horrifically hard (this has improved in recent MSVS generator integration, but I'm stuck w/ VS2008 still).
SBT has issues (I'd say performance primarily), but works really nice for what it does, IMO. Virtually no configuration required (for a simple project you only need to specify dependencies and maybe import IDE plugins), scriptable in a full JVM-based turing-complete language (Scala), sane per-project dependencies (packages are cached globally for the user, but whitelisted classpaths are dynamically generated for each project), and a consistent design (SBT plugins are really just library dependencies of the build itself, for example).
There is exactly one build system I have ever liked. It was the one they used at Google. Unfortunately it's not available outside of Google so I don't get to use it now.
However if it ever became available outside of Google then I would use it absolutely everywhere.
I was working on adding unusual steps to the build. Things like "run the Protocol Buffers compiler on these files" (which, in the end, I just did through a batch file), and making sure the solution could be built on our CI server (at the time, that was Cruise Control but we eventually switched to Jenkins). It was no worse than Apache Ant in my experience (but I'm no fan of Apache Ant).
The project I worked on was relatively new. Another project had been started in Visual C++ 6 and upgraded multiple times over the years. Occasionally, somebody would go through the solution file and project files to see if we were doing silly things because of this evolution (e.g., defining rules that weren't ever used). And we had two or three ways of setting paths so that developers could check out the code and build without worrying too much. Especially when it came to projects that needed DLLs from other solutions.
We were able to reduce the amount of annoying things to a tolerable level. I believe they moved to something like NuGet (for some things) after I switched jobs.
I think some javascript build systems are getting better, like Gulp. I'm starting to think that most build systems could/should be written in javascript from now on since you then have a scripting language that probably will run on most systems.
Which... the reason it sticks out with me is that really good rants are a lot more memorable to me than people talking about what software they like, which is probably not a fair way to evaluate software.
