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.

3

It’s a reasonable feature request. Almost everything else gets stuffed into different per-config folders, I don’t see why compile_commands need be excluded from that.

It would be some global option passed to CMake.

4

I also have a consulting client who post-processes the current compile_commands.json file to split it up into config-specific files. Like the original poster, this is motivated by running tools like clang-tidy and iwyu. You want to avoid having to run those checks on all configurations, that’s unnecessary duplication. You normally just want to pick one configuration and run the checks for that only.

I’m sure it would be a welcome feature if CMake produced single-config compile_commands.json files in config-specific subdirectories when using a multi-config generator.