You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running compdb on the Linux kernel results in a compile_commands.json file that includes selftest headers and other files, even if they are not scheduled to be built in the current Kconfig.
The issue is that these headers are gated behind #ifdef CONFIG_XYZ options, but the logic in includedb.py doesn't take these ifdefs into account:
I tried running each compile command with the -E flag to see what files are included, and parsing the output. This... works? But incorporating this would incur A LOT of overhead, and you would need to reliably modify the commands from the compilation database without inducing other side-effects; such as removing the -o parameter so you don't overwrite object files, etc.
I am not suggesting compdb incorporate these changes— I am creating this issue to document the behaviour in case anyone else stumbles upon this. Perhaps this could be noted explicitly in the README?
Example
An edited and contrived example, to demonstrate what I'm talking about:
I wrote a separate tool to do what I described above: run each command to the preprocessor stage by modifying the compilation commands to add -E and remove -o: https://github.com/roddux/header_fixer
Issue
Running
compdb
on the Linux kernel results in acompile_commands.json
file that includes selftest headers and other files, even if they are not scheduled to be built in the currentKconfig
.The issue is that these headers are gated behind
#ifdef CONFIG_XYZ
options, but the logic inincludedb.py
doesn't take theseifdef
s into account:compdb/compdb/includedb.py
Lines 102 to 114 in c145d02
Solution?
Solving this is likely difficult!
I tried running each compile command with the
-E
flag to see what files are included, and parsing the output. This... works? But incorporating this would incur A LOT of overhead, and you would need to reliably modify the commands from the compilation database without inducing other side-effects; such as removing the-o
parameter so you don't overwrite object files, etc.I am not suggesting compdb incorporate these changes— I am creating this issue to document the behaviour in case anyone else stumbles upon this. Perhaps this could be noted explicitly in the README?
Example
An edited and contrived example, to demonstrate what I'm talking about:
The text was updated successfully, but these errors were encountered: