> Well, currently all these parts, such as the "server" and
"front-end", are managed from the IDE.
Yes, but isn't compile_commands.json content a black box to the front-end? i.e. its an output file of one tool (e.g. cmake) passed as an input file to another tool (e.g. clangd).
> For example if user adds the source file - it needs to be added to
json as well,
This is the part I don't understand - at the moment the compile_commands.json file is written by non UI tools. The UI tools may be involved in creating things like cmake files, etc. Any new tool that comes along also needs to be able to translate a human readable file into a compile_commands.json, but that tool needs to operate at the command line (headlessly) to be useful.*
What is your vision for the UI writing compile_commands.json? i.e. what am I not understanding about your use case?
Thanks,
Jonah
* The lack of a good headless build and human readable input file in CDT managed builder has long affected its adoption. There is an Eclipse application for building, but it was an afterthought.
Well, currently all these parts, such as the "server" and
"front-end", are managed from the IDE.
For example if user adds the source file - it needs to be added to
json as well, and we need to guess the commands for this new unit,
and for this we need to know how the surrounding units are
configured.
Yes, LSP people do need the access to "compilation
database", either to a parser directly or better to a
service that can query compile_command.json
Thanks Alexander. Can you expand on this please? When
using LSP, what does the front-end need to read from
compile_commands.json? AFAIU the language server needs to
read the compile_commands.json file itself, so what
additional stuff does the IDE need to read? Perhaps I am
misunderstanding how this works?
