3 ms·

Benefits to CMake: IDE Support: KDevelop and CLion both support CMake as a flag ship project file. Why? A CMakeLists.txt has all you need: the project's debug

Benefits to CMake: IDE Support: KDevelop and CLion both support CMake as a flag ship project file. Why? A CMakeLists.txt has all you need: the project's debug/release build commands, include's for completions, and library files. Growing ubiquity: More and more open source projects are build around CMake CoreCLR, Swift, lua, SFML, opencv, cafe, zlib, libevent, blender, protobuf Some fast facts about these tools: - CMake is complicated. Sure, there are macros. But it's not a bad thing. CMake's complexity is proportional to what it takes to do the job: finding header files and libraries across platforms, detecting compiler features, and so on. - This isn't the kind of a job that can be solved by a simple, beautiful 50 line file. For instance: Stuff like finding SDL2 header files across platforms is hard because OS leave them in /usr/include, /usr/local/include, then within that, some keep them under SDL or SDL2 within that. Ergo, custom modules need to be built to handle the differences that have organically manifested in distros over the years. - In order to have software binaries built for as many platforms as possible, a build system needs to be able to test that certain functions exist. For instance, tmux: https://github.com/tmux/tmux/blob/45ee118/configure.ac#L427 https://github.com/tmux/tmux/blob/45ee118/configure.ac#L427. The only way for tmux to know if it should "polyfill" getopt is to run a small snippet of code. If your system has it, it stores HAVE_GETOPT. If not, it has to get fill in getopt at https://github.com/tmux/tmux/blob/45ee118/compat/getopt.c https://github.com/tmux/tmux/blob/45ee118/compat/getopt.c via https://github.com/tmux/tmux/blob/45ee118/compat.h#L352 https://github.com/tmux/tmux/blob/45ee118/compat.h#L352 - Understand the point of these kind of tools is solve a problem: Getting your source to build across a range of platforms, not just Ubuntu! - Not to mention, CMake has compatibility for various generator outputs. For instance, it can output Visual Studio projects, XCode projects, and even more popular, Ninja (https://ninja-build.org/ https://ninja-build.org/) - CMake gives leaves helpful debug output when so you can get help when you're troubleshooting (cmake --system-information sysinfo.txt)

santaclaus 9y ago
> This isn't the kind of a job that can be solved by a simple, beautiful 50 line file. As a big CMake fan, I don't think CMake's success has anything to do with their super ugly custom language. What CMake does could be a lot more ergonomic, especially from a typical user's standpoint.
- SXX 9y ago
  Typical user doesn't need project generation for 10 different IDEs, OS and packages formats with multiple backends and built-in test support. If you drop half of features then I guess it's could actually become a lot more ergonomic, but in this case there likely tools with better support. Real pain is that a lot of CMake features are badly documented and most of available information is outdated, but this is usual problem at least for open source C++ projects so it's doesn't cause a lot of frustration and no one try to fix it.
  - alacombe 9y ago
    We do, while we're not doing anything crazy, ie. support for 3 major OS (Windows, Linux, macOS), 3 major build-system (VC, GNU make, Xcode), 3 different compiler (VC, gcc, and clang), 7 different product packaging (RPM, DEB, TGZ, Windows, Mac, Alpine, Android), as well all kind of debug / release custom setup.
  - lomnakkus 9y ago
    Exactly. Another point I'd like to add here: CMake basically takes to you what autoconf/automake can do (+ 5/10 years of improvement on UX/UI), but it: a) doesn't use absurd amounts of slow shell code trying to detect features that no (non-EOL) OS has been missing for the last 20 years. b) is actually reasonably readable. (Ok, m4 is sort of readable, but it a bit weird in places.) c) is actually better documented (IME) than autoconf/automake. What people usually do for autoconf/automake is just copy/paste another project/snippet. .. hence leading to the 20+ years problem. (I'll definitely agree that the docs aren't great, but that's at least a problem that can practically be fixed unlike the copy/paste problem of autoconf/-make.)
SXX 9y ago
I would also mention there number of awesome tools exist for CMake (like Android support mentioned before). One of them I used on our project is MXE cross-compiler toolchain [1]. It's basically let you build CMake project for Windows from Linux by adding one toolchain option and it's have almost all popular libraries available. It's can be setup in like 10 commands at most and have pre-built packages for CI. [1] http://mxe.cc/ http://mxe.cc/

santaclaus 9y ago

> This isn't the kind of a job that can be solved by a simple, beautiful 50 line file. As a big CMake fan, I don't think CMake's success has anything to do with their super ugly custom language. What CMake does could be a lot more ergonomic, especially from a typical user's standpoint.

SXX 9y ago
Typical user doesn't need project generation for 10 different IDEs, OS and packages formats with multiple backends and built-in test support. If you drop half of features then I guess it's could actually become a lot more ergonomic, but in this case there likely tools with better support. Real pain is that a lot of CMake features are badly documented and most of available information is outdated, but this is usual problem at least for open source C++ projects so it's doesn't cause a lot of frustration and no one try to fix it.
- alacombe 9y ago
  We do, while we're not doing anything crazy, ie. support for 3 major OS (Windows, Linux, macOS), 3 major build-system (VC, GNU make, Xcode), 3 different compiler (VC, gcc, and clang), 7 different product packaging (RPM, DEB, TGZ, Windows, Mac, Alpine, Android), as well all kind of debug / release custom setup.
- lomnakkus 9y ago
  Exactly. Another point I'd like to add here: CMake basically takes to you what autoconf/automake can do (+ 5/10 years of improvement on UX/UI), but it: a) doesn't use absurd amounts of slow shell code trying to detect features that no (non-EOL) OS has been missing for the last 20 years. b) is actually reasonably readable. (Ok, m4 is sort of readable, but it a bit weird in places.) c) is actually better documented (IME) than autoconf/automake. What people usually do for autoconf/automake is just copy/paste another project/snippet. .. hence leading to the 20+ years problem. (I'll definitely agree that the docs aren't great, but that's at least a problem that can practically be fixed unlike the copy/paste problem of autoconf/-make.)

SXX 9y ago

I would also mention there number of awesome tools exist for CMake (like Android support mentioned before). One of them I used on our project is MXE cross-compiler toolchain [1]. It's basically let you build CMake project for Windows from Linux by adding one toolchain option and it's have almost all popular libraries available. It's can be setup in like 10 commands at most and have pre-built packages for CI. [1] http://mxe.cc/ http://mxe.cc/