[MaxBarraclough]

There's also Premake, [0][1] Buildout, Ninja, SCons, and no doubt there are others. qmake was recently deprecated.

It would take a lot to persuade me to move away from CMake and to use something 'non-standard' that few developers are familiar with:

* Excellent support for command-line builds on Unix

* Excellent support for Visual Studio

* Excellent cross-platform package-detection. (Acid test: Can it detect and link against OpenCL without me having to write my own cross-platform OpenCL-detection script?)

* Excellent documentation, including clear and consistent best practices and design patterns

* A sensible language, whether a scripting language or a declarative language. Must follow the principle of least astonishment and be relatively free of foot-guns. (CMake fails tragically on both counts.)

[0] https://premake.github.io/

[1] https://en.wikipedia.org/wiki/Premake

[knorker]

I can't speak for MSVC support, but to me CMake fails all other bullet points. especially cross-platform package detection.

I haven't seen anything except autotools get this right.

[MaxBarraclough]

> especially cross-platform package detection

I disagree here. CMake has working FindXyz modules for most major libraries. To write one of those modules is an exercise in soul-destroying tedium, but there's a pretty impressive body of existing modules out there, many of them officially bundled with CMake.

When used correctly, both CMake and Autotools are capable of robust package-detection.

Regarding point 1: CMake works pretty well on Unix, but it's a pity there's a runtime dependency on the CMake package. Autotools is much better in that particular regard: just about any Unix system can run a configure script, as it's just a plain old shell script.

CMake certainly falls short on the final 2 points, as I rambled about at https://news.ycombinator.com/item?id=24203172

It's too late for me to edit my earlier comment, but here's another alternative to CMake for the list: Bazel.

[tn1]

> CMake has working FindXyz modules for most major libraries

Unless you have that library installed anywhere that is not /usr/include Then you have to just hope and pray that there's some magic incantation that will make it find the right one (especially if your system-installed version is the wrong version and you'd really like to use the newer version you installed to $HOME)

[MaxBarraclough]

Right, but it's always like this. If you're on Windows and you install Boost to C:\random\directory, it seems fair that CMake will require you to specify that directory manually.

The alternative is to have a global database, like the Windows registry or like pkg-config (which I have to admit I don't know much about). Perhaps CMake could have better support for pkg-config, I don't know.