More practically a Compilation Database is most often serialised as a JSON file and comes out of the Clang tooling world. That includes the filename, all flags and other arguments to be passed to the compiler and the directory to invoke the compiler from (this affects relative paths). In the most general terms a Compilation Database is simply the collection of all information needed to compile a source file, or set of source files – on a file-by-file basis. To find out why we need to look at what a Compilation Database actually is. This is just the start, but is also a lot more useful already than you may realise. The initial results of that ongoing work have been: support for Cargo (for Rust projects) in 2018.1, a third-party plug-in for Bazel, and, in 2018.2, Gradle C++ projects and the ability to open Compilation Database JSON files. While this is a great starting point, we do want to support other build systems and project formats and work has been progressing over the last couple of releases towards fully decoupling CMake. In fact that is really the only way works, although CLion uses it in a way that mostly hides that from you by default (generating Makefiles behind the scenes). It can generate build files for other major build systems. Instead it’s because CMake is in very widespread use – especially in the open-source world, where it has become the de-facto standard.ĬMake also has the advantage that it is a meta-build system. That’s not because we think it is perfect (although it’s worth noting that some of the issues that people have with it may be addressed by focusing on “Modern CMake”).

There are many good reasons for needing to use something different – but if you could only pick one we still feel CMake is the best choice.

One of our most frequent feature requests for CLion is the ability to use project or build systems other than CMake.

Clion makefile for windows