Here's what you get for free:

https://www.gnu.org/software/make/manual/html_node/Catalogue...

As you can see, it takes flags and compiler from the environment.

It seems that in order to use the default rules, the target name needs to have the same name as the source file, e.g.

    file: file.cpp

so specifying the "exe" filename as the output seems to be already a custom rule, so it doesn't seem to work without manually calling the selected compiler.

Another issue is that indeed, CFLAGS is supported by default (implicit) rules, but as soon as the user tries to build a custom rule (which is 99% of the time), the support is lost unless explicitly adding it.

Third issue is that it seems that implicit rules can be different by different implementations of make, i.e. BSD make can have different rules than GNU make. Even if we consider only one implementation, then default rules can be different to each platform. The docs state that the user should consider the output of the `make -p` command in order to see the rules, which gives me an impression that different implicit rules can exist on different Linux distros, depending on how `make` was compiled (not sure what is the de facto state).

I mean, it doesn't sound simple.

Yep. In practice, make gets bigger. cmake also ends up looking like this: https://github.com/opencv/opencv/tree/4.x/cmake

Trivial examples look nice enough in either system, big ones look bad in make and utterly fucked in cmake. Some of this is that people keep trying to write things in cmake scripts that should be external programs in a workable language.

To be honest, I'm not sure what is your point. Does the number of lines increase when the project complexity increases? Yes. Is CMake harder to read if the build system increases in complexity? Yes. The point of a minimal example when reasoning about CMake is to show that you get much more free stuff than in Make, not that it always stays small.

Putting an equal sign between CMake and Make, because the complexity increases in both, is pretty ignorant IMO. It's like saying "A car is no better than a bicycle, because both have problems with tires when driving long enough".

You have pasted a link to a complicated build system, which would be impossible to write and maintain in manual Make. It would require using Autotools. But then the Windows support would be dead. And lots of the files from the directory you've pasted are there in order to interface with hard-to-interface autotools-based build systems.

You can check out libarchive, which has support for both Autotools and CMake: https://github.com/libarchive . I'm not saying it uses both build systems the best possible way, but I pick CMake build over Autotools any day. What I get for free?

- I can open the project in my favorite editor and I have clangd working automatically,

- I can open it in Visual Studio, CLion, Eclipse, or whatever,

- I can create multiple configurations (release, debug, asan, clang, gcc, vs2019, vs2022), comple them all and run tests for all configs at the same time after each change,

- When changing the build system itself, I don't need to think in layers: first the M4 layer, then the bash layer (or was it sh?), then the /bin layer -- "is my option passed to "cp" accepted on OpenBSD or is it a GNU extension? I better quickly install an OpenBSD VM and check it."