User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
(LSP again, we need another thread if you would like to continue)
17.06.2020 16:22, Jonah Graham пишет:
(All of this is in context of LSP type use cases)
> 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).
I would say the "toolchain" abstraction does not fit well here. Yes,
for a particular sequence of calls it works like this. But between
the "sequences" the cc.json needs to be queried/updated.
> 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.*
The question is complex enough to be described shortly. And you are
right, it is very important who and how can access the cc.json.
But I never suggested to restrict the scenario with UI only. I'm
talking about headless API to be triggered on "translation unit
added", and this is very different from handling LSP
"textDocument/didOpen", because where was no "open in UI" request
yet and it may not happen at all. If the plan is to run the full
loop with cmake to re-generate the cc.json on every structural
change - it will never scale.
Again, this is just an example that appears during IDE work and may
be useless during batch build.
What is your vision for the UI writing
compile_commands.json? i.e. what am I not understanding about
your use case?
I am the last person to be suspected of including a UI tool in the
headless chain. I'm always trying to avoid UI dependencies as much
as possible, you can see the "memory transport" work for example.
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?
