easy, CMake 3.xx or higher is required.

So… a build of CMake from within the last 8 years? Seems like a reasonable requirement.

I haven't tried CMake recently but I remember using it in 2012 and it was awful - the documentation was unhelpful and as soon as I tried to do anything not in the examples I was on my own.

I'd love to hear why you think that's a bad thing. IMHO it's a huge quality of life improvement over 2.x. Everything is part of a target (flags, defines, dependencies, etc.) and far, far fewer magic variables that pollute random projects whenever you try to compose them.

Cmake is confusing as all get out. Make follows the Unix philosophy of just doing one thing - call other programs. It comes with almost all tool chains you’d care about. You can pick up the basics of a makefile in an afternoon… I still don’t know where cmake functions come from, how you would know about them or how to write your own. Let alone which version is the right one.

It’s like jsonnet to me - if you need config files that make config files something has gone horribly wrong.

Then again, I stopped bothering trying to learn Cmake. If I see Cmake I don’t bother with the project so there’s that - and also not a fan of c++ so I am probably the wrong audience anyway.

What is confusing about CMake?

    cmake_minimum_required(VERSION 3.5)
    add_executable(exe file.cpp)

Do you think that's more complicated than the basics of a Makefile? [1]

[1]: https://anadoxin.org/blog/is-it-worth-using-make.html/

There are very few projects for which the above CMakeLists.txt would be enough. Once your project reaches a certain size you will inevitably end up in a part of CMake that is confusing.

Well, first argument is that it actually IS enough for lots of small tools, and second argument is that if it's not enough and must be extended, it still requires much less complication than an equivalent Makefile.

The comparable makefile:

    exe: file.cpp

Default rules take care of the rest.

And if you argue that the barebones example is insufficient for a real project: absolutely true. The same applies to your cmake example.

What do you mean it's comparable? Does it support multiple compilers? CFLAGS? Out of source builds? "compile_commands.json" generation? Automatic header dependency monitoring?

Also I've actually checked that Makefile, and it errored out (macOS):

    make: Nothing to be done for `exe'.

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."

Only if you are talking about bare bones POSIX compliant makefiles, which most definitly aren't, hello autotools.

> I still don’t know where cmake functions come from, how you would know about them or how to write your own.

There is a lot to criticize about CMake, but this is just RTFM level silly.

if you rarely have issues, either someone else dealt with them before you knew it, either your project is very simple, either your project doesn't ever change or all of the above.

I would like to work with your devops :)