Ninja Multiconfig, compile_commmands.db, and clang tools

Code
1

The compile_commands.db that is generated with multi config not unreasonably has commands for all of the configurations. This confuses clang tools, like clang-tidy and clangd, that parse the database. Running configure just to produce a single configuration database seems very wasteful. Is there already a tool to export just the compile_commands.json for a single config?

For reasons that seem good to me, I don’t want to run clang-tidy as a co-compile command. In particular I have some quite expensive plugin checks that I don’t want to run all the time, nor do I want to compile at the same time as I’m running those checks.

I can cruft together one with shell and jq, of course, and have for now, but it would be nice if I could ask cmake or the generated buildsystem to produce it for me, or if cmake could just drop them into e.g. /{Debug,RelWithDebInfo,etc} already split, as well as the full one in the root.

2

I see no compelling reason to use Ninja Multi-Config.

If you already use separate CMake presets and build directories for configurations such as:

build/debug
build/release
build/coverage
build/asan

With the ordinary Ninja generator, each directory has exactly one configuration and therefore:

  • one unambiguous compile_commands.json;
  • correct configuration-specific module information;
  • predictable clangd, clang-tidy, IWYU, and coverage behavior;
  • no repeated run-clang-tidy analysis;
  • simpler scripts and CI;
  • independently cleanable build configurations.

Ninja Multi-Config is mainly useful when:

  • an IDE expects switching between Debug and Release inside one build tree;
  • generating/configuring the project is exceptionally expensive;
  • multiple configurations must share generated artifacts;
  • a workflow explicitly needs cross-configuration custom commands;

Those advantages do not fit your command-line, preset-based workflow particularly well. One build directory containing several configurations also makes tooling less clear rather than simpler.