DumpCompilationDatabase currently produces entries for -E, but these entries do not work for libTooling-based tools. This change adds to the check at the beginning of DumpCompilationDatabase to make it return without writing anything if -E is specified.
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 25160 Build 25159: arc lint + arc unit
Event Timeline
I don't understand the point here. Why would you want to include pre-processing-only commands in the compilation database?
Sorry for not being clear enough.
I don't want to include entries with -E. However, in the Linux kernel build, some build commands with -E occur after the regular build step, and that means that without the append option, the output .json file for those objects gets overwritten with a useless entry.
I originally thought that the simplest fix was to add a flag that appended to a json file instead of overwriting it. However, thinking about it some more, it would be nice if DumpCompilationDatabase refused to write such entries, since then I wouldn't care about the append version of this flag. I could drop the rest of this code (and fix the tests) if I could instead add the following after the check for -### at the top of DumpCompilationDatabase.
if (C.getArgs().hasArg(options::OPT_E)) return;
What do you think? I don't want to break anyone who depends on the current behavior of -MJ, but I think it's reasonable for DumpCompilationDatabase to output only entries it can use.
I'm sorry, but it still sounds to me like you want to address badly written build rules by making the driver more complicated. I don't see that is a reasonable goal forward.
Change CompilationDatabase to not output entries that use -E.
These entries cannot be used by the tooling, so they can be skipped. This removes the other code and adds tests to make sure that neither -E or -### entries write a file.
My goal is to build a compilation database for the Linux kernel so that I can use clang's excellent libTooling-based tools on it. I would like very much to do this in the least intrusive way possible both for the kernel and clang.
I also really like the -MJ flag, since I find it natural to ask the compiler to output a compilation database entry rather than depending on external tools. So, thank you for adding it.
Based on your feedback, I'm looking more deeply into the rules of the Linux Kbuild system to see if I can modify anything there. Preventing the -MJ flag from being passed to the -E invocations would prevent spurious entries from overwriting the entries that I need.
I think there's still an argument to be made for the code at hand, however, even though I understand that adding the check for -E adds code, hence makes the driver more complicated. In particular, I would argue that DumpCompilationDatabase should not output entries from pre-processing-only runs, since it appears to me that the other tools can't use those entries as input.
I've updated the patch to add only this check and tests now. Does this seem reasonable to you?