Especially since scons and cmake are in no way easy to learn, imho.

Still hell of a lot simpler than hand-writing Makefiles though. For both small and large projects.

I mean, a "hello world" CMakeLists.txt can be literally just this:

    add_executable(hello hello.c)

And it's cross-platform, can generate Visual Studio/Xcode/... projects, etc.

I think we have to go deeper than that to really see an advantage of cmake. A corresponding makefile would be:

    all: hello

That's not really complicated either.

Exactly. When evaluating a language / build system / whatever, it is definitely not sufficient to look at Hello World. You have to evaluate the worst case and average case if you want to get an idea of what you're in for. Looking at the "best case" (simple one-file project) tells you almost nothing except how hard it is to get started.

When evaluating build systems, one of my major questions is: How much "magic" will I have to work-around in order to do something off the beaten path that the build system's developers never considered?

This is a good criteria for languages as well.

The thing is that these are not equivalent hello worlds. I mean, if only for the fact that the cmake example does proper header dependency management, which is essential to correctly compiling c/c++ code as it changes. It's not something you can leave out of a makefile and still call it correct.

`scons` is very easy to start with:

    Program("main", ["main.cpp"])

The problems start once you want configure stages, build directories, portability and install targets, as all of those aspects are extremely lackluster and incomplete in `scons` and you have to reinvent large parts of the build system yourself essentially for anything even mildly complex.

`cmake` is much better. The language itself is ugly and takes some getting used to, so it's a little more complicated to get started with then `scons`. `cmake` generating `Makefile`s instead of actually building the project itself also adds a layer of complexity. But once you understand the basics it's much easier to get a fully functioning build going, including configure stages, build directories, portability and all that, as cmake has all of that integrated and working right out of the box.

`cmake` feels like a complete build system, while `scons` feels like a good start for a build system that was abandoned at the halfway point.

I still use plain `make` for some Python projects (mostly .PHONY targets to run `pylint`, `autopep` and friends), but for everything that needs to get compiled `cmake` is much easier to use than plain `make`, as you don't need to reinvent a build system yourself, it already comes with almost everything you need.

cmake is arguably easier to learn than make

and I argue with your conclusion.

Still easier than make...

hello.c in a directory

make hello

Easier?

I would not be using cmake if this repository did not exist:

https://github.com/Akagi201/learning-cmake

$ ls src

demo.cxx demo_b.cxx CMakeLists.txt

$ cat src/CMakeLists.txt

cmake_minimum_required (VERSION 2.8.11)

project (HELLO)

add_executable (helloDemo demo.cxx demo_b.cxx)

$ mkdir bin

$ cd bin

$ cmake ../src

SNIP

$ make

$ ./helloDemo

# SConstruct file env = Environment() hello = Program(["hello.c"])

$ scons