395
Make (or rather a Makefile) is a buildsystem - it drives the compiler and other build tools to build your code.
CMake is a generator of buildsystems. It can produce Makefiles, it can produce Ninja build files, it can produce KDEvelop or Xcode projects, it can produce Visual Studio solutions. From the same starting point, the same CMakeLists.txt file. So if you have a platform-independent project, CMake is a way to make it buildsystem-independent as well.
If you have Windows developers used to Visual Studio and Unix developers who swear by GNU Make, CMake is (one of) the way(s) to go.
I would always recommend using CMake (or another buildsystem generator, but CMake is my personal preference) if you intend your project to be multi-platform or widely usable. CMake itself also provides some nice features like dependency detection, library interface management, or integration with CTest, CDash and CPack.
Using a buildsystem generator makes your project more future-proof. Even if you're GNU-Make-only now, what if you later decide to expand to other platforms (be it Windows or something embedded), or just want to use an IDE?
- 2thank you! Just to confirm, that if I only program on Linux environment than only makefile is adequate but if I want the program from Linux to run in Mac than cmake is better option as I understand that, we don't need to make a new makefile on the Mac but rather just run the cmake. Is that the whole point? – rish Sep 12 '14 at 10:17
- 5@rish Yes, that's the gist. Note however, that there's more ways to program on Linux than Makefiles - see e.g. QtCreator, KDEvelop, Ninja. For each of these, it's either "create a project and keep it in sync with the Makefile," or "re-run CMake." And, as the answer mentions, CMake has other functionality too, like dependency discovery (e.g.
find_package()
) or testing/packaging support. – Angew is no longer proud of SO Sep 12 '14 at 10:22 - 3I read that CMake cannot create non-recursive makefiles. Is that still true? – Maxim Egorushkin Sep 12 '14 at 15:17
- 1@Angew Non-recursive is when make is invoked once with complete project dependency tree. As opposed to recursive when a top level makefile invokes sub-project makefiles in certain order. – Maxim Egorushkin Sep 12 '14 at 15:24
- 3This is an important weakness of CMake - GNU make has its wrinkles, but if you take the time to learn it, it is extremely powerful and versatile, and works on an enormous amount of platforms. Not having a complete dependency tree to analyze is a major flaw, just google for 'recursive make considered harmful'. – Erik Alapää Dec 23 '15 at 7:39
The statement about CMake being a "build generator" is a common misconception.
It's not technically wrong; it just describes HOW it works, but not WHAT it does.
In the context of the question, they do the same thing: take a bunch of C/C++ files and turn them into a binary.
So, what is the real difference?
CMake is much more high-level. It's tailored to compile C++, for which you write much less build code, but can be also used for general purpose build.
make
has some built-in C/C++ rules as well, but they are useless at best.CMake
does a two-step build: it generates a low-level build script inninja
ormake
or many other generators, and then you run it. All the shell script pieces that are normally piled intoMakefile
are only executed at the generation stage. Thus,CMake
build can be orders of magnitude faster.The grammar of
CMake
is much easier to support for external tools than make's.Once
make
builds an artifact, it forgets how it was built. What sources it was built from, what compiler flags?CMake
tracks it,make
leaves it up to you. If one of library sources was removed since the previous version ofMakefile
,make
won't rebuild it.Modern
CMake
(starting with version 3.something) works in terms of dependencies between "targets". A target is still a single output file, but it can have transitive ("public"/"interface" in CMake terms) dependencies. These transitive dependencies can be exposed to or hidden from the dependent packages.CMake
will manage directories for you. Withmake
, you're stuck on a file-by-file and manage-directories-by-hand level.
You could code up something in make
using intermediate files to cover the last two gaps, but you're on your own. make
does contain a Turing complete language (even two, sometimes three counting Guile); the first two are horrible and the Guile is practically never used.
To be honest, this is what CMake
and make
have in common -- their languages are pretty horrible. Here's what comes to mind:
- They have no user-defined types;
CMake
has three data types: string, list, and a target with properties.make
has one: string;- you normally pass arguments to functions by setting global variables.
- This is partially dealt with in modern CMake - you can set a target's properties:
set_property(TARGET helloworld APPEND PROPERTY INCLUDE_DIRECTORIES "${CMAKE_CURRENT_SOURCE_DIR}")
;
- This is partially dealt with in modern CMake - you can set a target's properties:
- referring to an undefined variable is silently ignored by default;
- 2Some good information here, but one remark is completely wrong: cmake has a LIST type since with proper LIST functions which is crucial for lots of build-system tasks, a bit difference: cmake.org/cmake/help/git-master/command/list.html – solvingJ Feb 18 '20 at 4:01
- 1I wouldn't call it "completely" wrong, but thanks for correction. – Victor Sergienko Feb 27 '20 at 22:56
- @VictorSergienko, Not asked in the OP's question, but I was waiting for the punch line...What do you use which you feel is better than either? – Robert Lugg Dec 23 '20 at 21:42
- I use make for historical reasons, and I hate it. CMake is not without problems too (try cross compiling with it), but for my own projects CMake would win because you write fewer code, and it’s supported by tools. – Victor Sergienko Dec 24 '20 at 1:57