# Postprocessing of Compilation Database
**URL:** https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688
**Category:** Usage
**Created:** [August 7, 2023, 10:55am UTC](https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688 "2023-08-07T10:55:50Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Steffen\_Nuessle](https://discourse.cmake.org/u/Steffen_Nuessle)
#### Post date: [August 7, 2023, 10:55am UTC](https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688/1 "2023-08-07T10:55:50Z")
Hello,
projects dealing with compilers targeting embedded systems (Greenhills,
TASKING, HighTec, etc.) have to use compile flags not known to e.g.
clang tools. This often leads to such tools completely bailing out
during command-line processing. One possible workaround for this issue
is to remove problematic compile flags from the compilation database
during the build process with add\_custom\_command() / add\_custom\_target().
However, I’d rather prefer having the compilation database patched
directly after it has been generated, but still during cmake’s configure
step.
1. Is there already a “nice” way to do some kind of postprocessing of
the compilation database during cmake’s configuration step?
2. If not, would it be feasible to add a feature to cmake which makes
this possible?
I would be willing to give it a chance and make a contribution to cmake,
but I would need some initial pointers to get me moving into the right
direction.
3. Is there a completely different approach which would solve my issue?
E.g. is it possible to _not_ export all used compiler flags into the
compilation database?
Any help is appreciated.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 7, 2023, 11:34am UTC](https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688/2 "2023-08-07T11:34:27Z")
> [@Steffen\_Nuessle](#):
>
> Is there already a “nice” way to do some kind of postprocessing of
> the compilation database during cmake’s configuration step?
No; it is written out at generate time, so there’s little control available over its contents.
> [@Steffen\_Nuessle](#):
>
> If not, would it be feasible to add a feature to cmake which makes
> this possible?
In general, the tools need to understand the compiler in use. I think it may be easier to get the project to also compile under `clang` where you know the flags are compatible with a matching `clang-tidy`.
> [@Steffen\_Nuessle](#):
>
> s there a completely different approach which would solve my issue?
> E.g. is it possible to _not_ export all used compiler flags into the
> compilation database?
You might be able to use `CMAKE_CLANG_TIDY=wrapper` where `wrapper` sanitizes the flags for `clang` and then passes them off to `clang-tidy` (or whatever).
---
### Author:  [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [August 7, 2023, 12:56pm UTC](https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688/3 "2023-08-07T12:56:14Z")
Or you teach the tool to ignore unknown command line options.
Most tools are way too strict these days. Mostly combined with a weird set of arguments that matches nothing else. Also mostly for no reason.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 7, 2023, 2:03pm UTC](https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688/4 "2023-08-07T14:03:37Z")
Silently ignoring unknown flags is a wonderful way to get “well, it passed but it shouldn’t have” wild goose chases. At least warning noise about “ignoring flag `-X`” would help find these problems.
---
### Author:  [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [August 7, 2023, 3:15pm UTC](https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688/5 "2023-08-07T15:15:27Z")
Better than the usual “oh, an unknown argument, let’s quit” behavior but even the warning should be configurable. Better than wasting developer time all around the world, forcing them to write weird wrapper scripts.
---
### Author:  [@Steffen\_Nuessle](https://discourse.cmake.org/u/Steffen_Nuessle)
#### Post date: [August 7, 2023, 4:54pm UTC](https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688/6 "2023-08-07T16:54:49Z")
In any case, my feeling is that none of the proposed solutions is better
than the current solution of just doing the postprocessing of the
compilation database during the build.
Adapting the parsing of the compilation database of every tool consuming
such a database seems too ambitious.
Rewriting the build system so it additionally supports a clang build is
also quite hard (various reasons; I won’t go into details) and bulky.
Using a wrapper is essentially the same as doing postprocessing during
the build or am I missing something?
In the long term, I am still considering extending cmake with a feature
to resolve my issue. It just feels like the best solution to me.
Adding a variable like CMAKE\_EXPORT\_COMPILE\_COMMANDS\_POSTPROCESSOR which
takes a program/script as a value comes to mind. Anybody able to make a
guess whether such a patch would be accepted upstream?
Mit freundlichen Grüßen
Steffen Nüssle
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 7, 2023, 5:46pm UTC](https://discourse.cmake.org/t/postprocessing-of-compilation-database/8688/7 "2023-08-07T17:46:49Z")
> [@hsattler](#):
>
> Better than the usual “oh, an unknown argument, let’s quit” behavior but even the warning should be configurable. Better than wasting developer time all around the world, forcing them to write weird wrapper scripts.
There’s already `-Wno-unrecognized-arguments`. If you want something like `-fignore-unknown-arguments`, I think LLVM developers would be the more fruitful path.