Compilation databases are JSON files that are formatted so as to specify how to replay single compilations independently of the build system.
It consists of “command objects”, where each entry specifies one way a translation unit is compiled in the project, that is: a working directory, a command including the compiler name with its include directories and definitions options and flags, as well as the file for which the object has been generated.
As stated on clang’s web site, tools based on the C++ Abstract Syntax Tree (AST) need full information how to parse a translation unit. This information is usually contained in various ways in the build system of a project.
The problem is that relaying only on such tools is not optimal as they are change driven and that figuring out wether things have changed is often an IO bound process.
But what are they useful ? Well, it is very efficient if you’re interested in source code writing analysis and source code rewriting tools. As an example, I’m using it for both code completion (using company) and linting (using flycheck) with emacs.
But how does one generate such compilation databases ? Well there is three ways I know of.
- If using cmake, simply pass the
- If using ninja, invoke
ninja -t compdb
- Otherwise, when ending up with Makefile, use
Bear, which stands for Build EAR
executes original build commands and intercepts the
issued by the build tool. This is achieved using code injection.