[
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 пишет:
(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`
`
workspace.didChangeWatchedFiles`
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
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
