Closed GPMueller closed 3 years ago
An issue implementing this in clang-build is the fact that we try to only generate as little info as actually needed. When a target is built the compile commands could be saved, but in a second build the target would not be in the build list and the compile commands would no longer be in the file.
It seems we would have to implement a more database-like behaviour, for example by reading in the file, updating the resulting dict and then saving again (instead of just overwriting every time). The question is: when should any entry from the database be removed and/or when should it be cleared entirely?
Since we generate the compile commands, we can easily write them into a compilation database.
From the clang documentation:
where
directory
: The working directory of the compilation. All paths specified in the command or file fields must be either absolute or relative to this directory.file
: The main translation unit source processed by this compilation step. This is used by tools as the key into the compilation database. There can be multiple command objects for the same file, for example if the same source file is compiled with different configurations.command
: The compile command executed. After JSON unescaping, this must be a valid command to rerun the exact compilation step for the translation unit in the environment the build system uses. Parameters use shell quoting and shell escaping of quotes, with ‘"’ and ‘\’ being the only special characters. Shell expansion is not supported.arguments
: The compile command executed as list of strings. Either arguments or command is required.output
: The name of the output created by this compilation step. This field is optional. It can be used to distinguish different processing modes of the same input file.This should improve the IDE experience, I believe it will for example help VS Code find includes and definitions, etc.