[cdt-dev] IDE and compile_commands.json

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

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)

 

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

 

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.