# Ninja Multiconfig, compile\_commmands.db, and clang tools
**URL:** https://discourse.cmake.org/t/ninja-multiconfig-compile-commmands-db-and-clang-tools/15838
**Category:** Code
**Created:** [September 16, 2026, 4:26pm UTC](https://discourse.cmake.org/t/ninja-multiconfig-compile-commmands-db-and-clang-tools/15838 "2026-09-16T16:26:48Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Steve\_Downey](https://discourse.cmake.org/u/Steve_Downey)
#### Post date: [September 16, 2026, 4:26pm UTC](https://discourse.cmake.org/t/ninja-multiconfig-compile-commmands-db-and-clang-tools/15838/1 "2026-09-16T16:26:48Z")
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.
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [September 16, 2026, 7:12pm UTC](https://discourse.cmake.org/t/ninja-multiconfig-compile-commmands-db-and-clang-tools/15838/2 "2026-09-16T19:12:26Z")
I see no compelling reason to use `Ninja Multi-Config`.
If you already use separate `CMake presets` and build directories for configurations such as:
```auto
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.
---
### Author:  [@vito.gamberini](https://discourse.cmake.org/u/vito.gamberini)
#### Post date: [September 29, 2026, 6:24pm UTC](https://discourse.cmake.org/t/ninja-multiconfig-compile-commmands-db-and-clang-tools/15838/3 "2026-09-29T18:24:00Z")
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.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [September 29, 2026, 9:28pm UTC](https://discourse.cmake.org/t/ninja-multiconfig-compile-commmands-db-and-clang-tools/15838/4 "2026-09-29T21:28:57Z")
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.