You need to, in general, run the build for compilation databases to actually work anyways. Consider the following cases:

- headers generated during the build: tools may find the wrong header or fail when the header isn't found - generated sources: does the source file in the database even exist yet?

For those cases, one still needs to consider the "out of date" situation where a previous build left an old version around. This is something tools can't really even know today.

Beyond that, modules present an issue. The command line doesn't have any indication of what `import foo;` means to the TU in question (and in CMake's case, the file which does tell it that information is build-time generated anyways). Even if it did, the BMI may be in an incompatible format (e.g., using GCC for the build, but using `clang-analyzer` on the database) so the tool needs to go and make its own BMI. I gave a talk at CppCon about "build databases" which is basically "compilation databases, but consider what it means to support modules". (The video isn't available yet.)

I'm also working on getting a paper on them through ISO C++'s SG15 (Tooling) for proper specification.

FD: CMake developer