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.

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 straight-up like autotools, even though it's a bit warty.

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.

I like autotools more than MSBuild if that's any reference...