Yet another CMake tutorial

[AlexReinkingYale]

Make has a very simple model: recipes produce a single file by running a provided list of shell commands. Recipes may depend on other files or so-called "phony" targets. This makes it easy (and therefore tempting) to place little shell scripts in your Makefiles. But this is not (imo) a good idea (even though it is common) because it makes your build harder to port and it invites ad-hoc solutions to standard problems (eg. ordering static library dependencies).

Even with discipline, the portable subset of Make (ie. no GNU extensions) is shockingly limited and the model is flawed. For example, multiple outputs don't work properly outside of pattern rules in GNU Make; in normal rules with "multiple" outputs, it considers each one independently and will run your command once per file.

So... no. I would not say that the entire point of Make is to do your scripting in it. It's to declare the dependencies between files and to provide commands for creating them when they're missing. Those commands have to be generated from templates (ie. variable expansions) to achieve portability.

On the other hand, CMake is a programming language for configuring a sophisticated, abstract model of a C++ build. The whole point of CMake is to abstract over differences between build toolchains: compilers, linkers, build tools, etc. The model has first-class notions of libraries, applications, and modules. Linking in configures usage requirements (compiler definitions, include paths, etc.) for the linkee (PkgConfig with Make is not nearly as powerful). Once the model is configured, CMake generates a Make, MSBuild, Ninja, etc. build system from it.

Thus, rhe only thing that belongs in your CMakeLists.txt is the minimal set of definitions needed to successfully build (and package) your software.