For C++ on Windows, I've been preferring development in Sublime Text, rather than Visual Studio. It's more lightweight, there's less magic going on and I've got it configured the way I like. And I really hate VC++'s filtered folder project system. I just want to see my source directory and not have to screw around with the project file every time I want to add a child folder. Also, as someone from a non-C++ background, I feel I am learning more by running my own build script (just a custom PowerShell script at the moment) and having it run CL.exe. CMake is all well and good, but my project is built around a large number of plugins which each have to be built separately, and... well I guess the way CMake clutters up my folders with a million files just irks me a bit. That, and I've read a number of stories from other projects where the developers were complaining about CMake problems that made their lives harder rather than easier on Linux. I like things to be simple and clean.

Even so, I know that maintaining your own set of build scripts can get complicated and be a pain to maintain, particularly when you want to target the other major OS's as well. CMake's not the only show in town. What do you guys think about Boost's build system? I built Boost for the first time a few weeks ago and found the build process to be very clean and straightforward. Still, CMake seems to be what the majority of dev teams gravitate towards, so I'd like to get the opinions of those more experienced than myself with cross-platform C and C++ development. If you know of something else really solid as well, I'd be interested in that as well.

I'm unhappy with quite a few bits of CMake.

However, I also haven't found anything yet I would use to replace it. I have come to accept that build system generators are probably always going to be quite a bit messy.

That said, at work we need a largish project (or at least parts of that project) to build on four different platforms. I know from experience that whatever hoops CMake requires of us to jump through is much better than having to deal with the platforms individual build systems by hand.

Even at home for my personal projects I'm using CMake though. It is used by a lot of people nowadays which means you find quite a bit of information when you get stuck. Finding important details about the other build system generators can get quite a bit more difficult. Increasingly many projects come with CMake right out of the box too. While some of them can be messy to integrate I have now found a few which you can just drop into your project 3rdparty subdirectory and integrate seamlessly as a dependency (not that important on *nux but reduces the pain on Windows if you want to).
It also integrates rather well with my IDE of choice (QtCreator) and should I decide to switch IDE at some later point the decision is just a CMake generate away.

the way CMake clutters up my folders with a million files just irks me a bit

I don't think I ever had that problem. Maybe you are doing something wrong?

If you know of something else really solid as well, I'd be interested in that as well.

Even at home for my personal projects I'm using CMake though.

[...]

It also integrates rather well with my IDE of choice (QtCreator) and should I decide to switch IDE at some later point the decision is just a CMake generate away.

I use the Qt Build Suite (Qbs) with Qt Creator on Windows. I find the project files to be simpler than the equivalent CMake ones.

Qbs supports multiple platforms; that said, I have only used it on Windows (with MinGW and VS2013), and don't know how well it works on other platforms. But I really like it on Windows. The examples (available in C:\Qt\Qt5.5.0\Tools\QtCreator\share\qtcreator\qbs\share\qbs\examples on my laptop) cover several useful use cases, and there is a really helpful quick reference as well.

I never wrote a single line of Qt code; I just find Qt Creator to be a really nice IDE, and Qbs a really nice build system. Combined with the compiler from VS 2013 and CDB, I think they make a powerful and snappy toolchain.

I don't think I ever had that problem. Maybe you are doing something wrong?

Very possibly. All I know is that when I run CMake on various different projects that are not mine, I end up with loads of solution files, with extra solutions like ZERO_CHECK and so forth, and a bunch of other accompanying files and folders, all cluttering up the root directory.

If you do an out of source build, you can isolate the generated cmake files to a build directory tree and avoid polluting your source.

That sounds ideal. I'll look into that, thanks.

I use the Qt Build Suite (Qbs) with Qt Creator on Windows

I must admit, the ugliness of the QT IDE makes my inner snobby designer twitch a bit... I bet it's really good though. Maybe I should look into it a bit more than I have...

I don't think I ever had that problem. Maybe you are doing something wrong?

Very possibly. All I know is that when I run CMake on various different projects that are not mine, I end up with loads of solution files, with extra solutions like ZERO_CHECK and so forth, and a bunch of other accompanying files and folders, all cluttering up the root directory.

The key problem is probably that you don't do a proper out of source build as JTippetts already suggested. Any build directory of a non-trivial project will be a bit of a mess. CMake has to add a bit on top of what you need there because it needs custom build steps to detect when it has to rerun itself, but compared to what a regular project already needs it's not really much. In all the IDEs I know those are placed rather unobtrusively though.
CMake makes out of source builds easy: you pick a source directory and the build directory where you want to place all generated files and the compiler does its magic (actually there is one generator which puts one extra file outside the build directory but that is only because one IDE cannot deal with it otherwise).
Personally I like to place my build directory as a 'build'-subdirectory of my source directory and set that directory to be completely ignored by source control. Others require the build directory to be completely separate (for example 'D:\projects\myproject' and 'D:\projects\myproject-build'.

Personally I like to place my build directory as a 'build'-subdirectory of my source directory and set that directory to be completely ignored by source control. Others require the build directory to be completely separate (for example 'D:\projects\myproject' and 'D:\projects\myproject-build'.

Yeah I do this too, irrespective of build system. I guess I just need to learn CMake a bit more than I have.