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.
Is there already a “nice” way to do some kind of postprocessing of
the compilation database during cmake’s configuration step?
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.
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?
No; it is written out at generate time, so there’s little control available over its contents.
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.
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).
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.
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.
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?
There’s already -Wno-unrecognized-arguments. If you want something like -fignore-unknown-arguments, I think LLVM developers would be the more fruitful path.