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.
You really need build system support. For example, Ninja can generate the file without actually doing the build because it knows everything it _would_ do.
Is this really a major problem? Is there any tool that supports generating the database without compiling? I think the answer to both of these is "no". In fact I can't even think of a reasonable case where it would be even a minor problem.
> In fact I can't even think of a reasonable case where it would be even a minor problem.
On my last project, a build took 2+ hours on a 128 core threadripper. It wasn't every day that the lowest level stuff changed, but it was probably once a sprint or so. Waiting 2 hours for the compilation database to be ready isn't tenable. Rider and Visual Studio could generate a usable model of the project in 2-3 minutes.
OK that does sound like an actual problem. But I think you would only be in a position to need to do it that way if you don't use CMake, Ninja, or one of those other tools. Bear works the way it does because it's kind of a hack. I have only wanted to use it for Make projects. If the problem is big enough for you and constant enough then you can switch tools to avoid having to compile. It's just an uncommon problem IMO.
CMake does but I think you have to attempt a build to get the database. On the other hand I don't think that should be necessary, as it is capable of generating Ninja build files.
Almost nobody is writing Ninja files by hand. If you have to write something along those lines by hand, Makefiles would make more sense than Ninja. If Ninja does support exporting commands, it's a use case that doesn't matter because almost everyone uses CMake-generated Ninja files.
The most obvious example is the build system of Chromium, which uses gn. They do have a wrapper script to actually generate the compile_commands.json file, but it's just a thin wrapper around Ninja's built-in capabilities. (I'm not sure that CMake's isn't, on that note; I'm pretty sure it's ability to build the database is in fact dependent on which generator you're using.)
