Generate compile_commands.json compilation database #944
Conversation
This prepares for building a compilation database later. The returned command is not currently used anywhere yet, so this commit should not change behaviour.
This is still very rough and unfinished.
does the added |
I think it does not, since I think editors will just request an analysis of the file that is being edited, which does not have these directives. For those line directives to be helpful, a language server such as So I'm afraid that this is just the hole we dug with this preprocessing. Anyone who is serious about using the compilation database with a third-party editor should probably use the "empty .ino file"-approach to work around this. |
|
I need this |
|
This is superseded by the already merged #1081. |
Please check if the PR fulfills these requirements
before creating one)
our contributing guidelines
What kind of change does this PR introduce?
New feature: Allow generating
compile_commands.jsonfile as a side effect of compilation, for consumption by editors and other tooling, as requested in Feature Request: Export compile_commands.json #849.What is the new behavior?
All compile commands (not linking and other steps) ran are output to a compilation database, a file called
compile_commands.json(see https://clang.llvm.org/docs/JSONCompilationDatabase.html for the format). This file can be used by editors (often usingclangorclangd) to provide code completion, navigation and diagnostics.Other information:
This is just a rough draft, that still needs more work, some decisions and some feedback. I wanted to quickly throw something together, which ended up a bit more work than I thought. The basics work, though this is probably more of a proof of concept that might need to be significantly restructured. Open points are:
CompilationDatabaseclass outside of thelegacy/builderdirectory (seemed good to not add more legacy), but now I'm unsure how to approach logging. It seems that the cli and builder code have distinct logging facilities, neither of which seems easily accessible. For now I just added "fmt.Print". Suggestions are welcome.compile_commands.jsonto the sketch directory, since that's where editors would look for it. I later realized that it would probably be good to also write a version to the temp build directory (note: I mean the/tmp/arduino-sketch-XYZdirectory, not thebuildsubdirectory of the sketch dir where the compilation result is exported), for any tooling that wants to inspect the copied and preprocessed sketch files.compile_commands.jsonto be written to the temp build dir, but the sketch dir version should really point to the original sketch files. This means that thefileelement in the json should be updated, but maybe also any compiler arguments that resolve to sketch files should have their paths updated. This should probably be applied generically (i.e. search replacing back to the original sketch dir) to all arguments, since we can't be sure what aplatform.txtdoes exactly. Alternatively, updating just thefilefield might be sufficient and can be done by passing the original filename around (does require significant refactoring, I think).-include=Arduino.hflag added (as suggested in Feature Request: Export compile_commands.json #849 (comment)). This is imperfect, but probably as close as we can get.compile_commands.jsonto the temp build dir can always be done, but writing to the sketch directory should almost certainly be opt-in (through commandline or config), to prevent user surprise and because the IDE and arduino-cli seem to try hard to prevent touching the sketch dir now. For arduino-cli, it might make sense to always generate the file in thebuildsubdirectory, along with the compiled program, and provide an option to also, or instead of, generate in the sketch directory itself (where it will be mostly automatically picked up by editors orclangd). For the IDE, some extra care should probably be taken to not generate this file in the sketch directory for unmodified examples, even if the user enabled it in the config.compile_commands.jsonfile. Ideally, any existing file should be read and merged, taking care to remove any extra entries (e.g. for deleted files), but only when compilation was successful (or at least complete). Alternatively, a complete list of files to be compiled could also be used maybe (even when compilation is aborted halfway).