Nitpick: despite its name CMake doesn't really replace make (actually you can use it to generate Makefiles instead), it's more of a build configuration system like autotools.

As for criticisms of CMake, when I used it I thought it worked pretty well but I think its CMakeLists syntax is atrocious. Not that it's not an improvement over the autotools, but at least these ones have the excuse of being built on top of a mountain of legacy subsystems with various quirks.

I would love it if one day you could put a CMakeLists.xyz in the project instead, where xyz was just a slightly nicer syntax, but with the same semantics, and compatible with regular cmake. Tbh I'm not sure how I would want xyz to look though.

> I'm not sure how I would want xyz to look though.

I'd want it to look like a standard scripting language of some sort.

really premake syntax looks nice https://github.com/premake/premake-core/wiki/Your-First-Scri... and it actually uses a real programming language :-)

Cmake is acceptable for distribution, but not for ease of development, in my experience. There should only be a single step needed to generate a correct build, no matter what has changed. Instead, some changes require running make (e.g. modifying existing files), while others require running cmake then make (e.g. adding new files, or changing header file includes). Why would I use cmake when I could just write a makefile to handle everything in a single step?

Granted, I've been moving more towards scons lately, as python is a much easier language to work with. My usual SConstruct will check whether I am making a python extension module, and will download pybind11 if I am. That sort of thing is still possible with make, but starts getting more painful.

Having to run cmake before make is usually avoidable.

If you aren't using globbing but are specifying source (and header files) explicitly, just running make will do the right thing. Just running make also checks if you have modified CMakeLists.txt and re-runs config generation.

Yes, don't use globbing to find source files! CMake doesn't record that the file list came from a glob operation, so it doesn't set up the dependency checking to handle it. (Not all targets support this sort of thing anyway. I bet GNU make does a good job of it, especially if you use gcc -MMD and pattern rules; I rather doubt Ninja supports it; Visual Studio definitely doesn't.)

With manually-specified source file lists, using the Ninja, GNU make, NMake and Visual Studio generators, I have had to re-run cmake by hand no more than a few times, each time seemingly due to a bug somewhere. (Possibly my fault... I can't remember having had to do this with my current project.) Aside from that it's good at detecting when relevant files have changed, CMakeLists.txt included, and reinvoking itself as part of the build.

CMake has plenty of horrid parts, and there's probably plenty of reasonable workflows that it doesn't support, but I have to say that I've found the day-to-day workflow perfectly satisfactory...

That certainly sounds like an issue with cmake, rather than with globbing in general. With a properly written makefile, or with scons, there is no issue whatsoever in globbing to find source files. This is one of the main reasons that I have stayed away from cmake, because needing to specify an explicit list of all source files is setting myself up for errors in the future.

What's probably happening is that most people don't mind, and the current behaviour maps neatly to the way most IDEs behave. And so there probably isn't the will to change it. CMake does have an issue tracker: https://gitlab.kitware.com/cmake/cmake/issues

Autotools also requires you to explicitly enumerate all of the source files that end up in your build, although it also properly sets up Makefile dependencies so you don't have to re-run autotools when you add a new source file (like you do with CMake)

You typically don't have to do this with cmake either. The build depends on the CMakeLists.txt file (and the files it depends on itself), which is where the list of source files is stored.

That's a pretty big if. If I have a standard layout with src and include directories, then I expect everything within the src directory to be included, which requires globbing. If I add a new file, then there is no reason to need to edit the CMakeLists.txt as well. Similarly, header files are explicitly listed in the source files. Having them duplicated in the CMakeLists.txt only introduces potential for error.

In my mind, anything that needs to be specified explicitly is an opportunity for error.

I'm sorry; didn't mean to imply there was anything wrong with CMake, meant more as a joke and to suggest that CMake is a new tool that requuires a learning curve, like anything new, hence people resist, until it becames so prevalent that one gives up resisting and invests the time to learn it. In my case, it was to get CLion's external library interface working so I could jump to definition in headers in /usr/local/include

> What's wrong with Cmake?

One line summary:

    set(MYVAR 1234 CACHE FORCE PARENT_SCOPE)

Well you're trying to mix up two different function signatures...

    # Sets the MYVAR variable in the cache
    set(MYVAR 1234 CACHE STRING "" FORCE)
    # Sets MYVAR in the scope above the current level
    set(MYVAR 1234 PARENT_SCOPE

Though cmake is definitely not a "pretty" language... Don't get me started about lists.

Sure... I should have just quoted the documentation, because the point is that any of these concepts exist:

    set(<variable> <value> [[CACHE <type> <docstring> [FORCE]] | PARENT_SCOPE])

> Don't get me started about lists.

Yes, by no means exhaustive!

Cmake is more of a replacement for autotools than for make.

Advantages: Good Windows support.

Disadvantages: Dictates the directory structure, much less flexible than autotools.

If you know shell, an existing autotools project can be modified easily.

If you want to do something special in cmake, first you need to go to Stackoverflow. If your are lucky, the thing you want to do is supported (often it is not).

All in all, I feel locked in by cmake - to the point that once the build works I'm less inclined to refactor because the directory structure cannot be changed easily.