Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] IDE and compile_commands.json

17.06.2020 17:48, Jonah Graham пишет:
On Wed, 17 Jun 2020 at 09:58, Alexander Fedorov <alexander.fedorov@xxxxxxxxxx> wrote:
(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.

I am not talking about toolchain abstraction. Simply who reads and writes files. (server reads cc.json, cmake writes cc.json, front-end treats as black box)
Yes, this will work perfect for read-only sources. Please try to consider more dynamic scenario, where we have translation unit add/remove/rename.
In theory there are requests/notifications to help us:
`textDocument/codeAction` + `workspace/executeCommand`

But in practice these requests are not supported well enough by LSP implementatons.


> 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.

Can you provide a concrete (implemented) example, for example how it is integrated in another "IDE" (like vscode or theia)? Or a similar abstraction for another language.
Ah if I could :) I'm working to create one but it will require resources beyond the level that I can spent at the moment. It greatly depends on both server and client capabilities. I'm not familiar yet with what was done in Theia regarding this, but VS Code is pretty far from supporting "repackaging"-scale refactoring and similar can be stated for clangd. And at least for VS Code the problem lies much deeper than LSP layer.

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.

And I would be the last person to accuse you :-) I am making the distinction between the language server and client. 

cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top