[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Thoughts on LSP / Clangd integration
|
Had a feeling this would happen. We're talking about clangd which is an executable built out of the clang/llvm source tree. It's a separate thing that IDE vendors that use it would redistribute. You don't need to install clang the compiler.
Doug.
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of kesselhaus
> Sent: Saturday, August 12, 2017 8:16 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] Thoughts on LSP / Clangd integration
>
> From my (especially Windows based) user point of view, I have just the
> following to add:
>
> I looked now for a long time on clang and it took a long time, until they even
> provided windows builds. A windows user is usually not expecting to compile
> the tools from source by themself, they expect binaries.
>
> The second thing, that the user expects from a toolchain (compiler) is, that it
> is working, and that the full way. The problem with clang is, that they place
> themelf as a *compiler* replacement, but not providing the full toolchain,
> which would require to have also the libs and runtimes. For this, you would
> need to install on windows either a gcc or even a MS Windows SDK /
> compiler, in order to actually create an executables.
>
> So, if I have to install either of MS or gcc compiler, why would I now install the
> clang? I don't see the benefit of it, since gcc now also provides much better
> failre reporting. I can't give any input on compiling performance, since I'm not
> doing C++ development, but only C.
>
> From your request, I also only see "our C++ editor" .. I guess, C++ gives you a
> lot of headache, but there is and will still be C (here we have now C11). The
> question is, if you go that direction, will the tooling still be able to cope with
> the languages for those, that don't used clang at all. As said above, clang is
> not providing the full toolchain to create a full binary. In that case, if you base
> your whole CDT tooling on that LSP4E / clangd, then you have to include it
> somehow into CDT, with the option for users to use their own, if they already
> have it locally.
>
>
> Am 30.07.2017 um 23:46 schrieb Nathan Ridge:
> > Hi folks,
> >
> > Doug has previously brought up [1] the topic of Clangd [2], a clang-based
> language server that implements the Language Server Protocol [3].
> >
> > The prospect of using Clangd to power a C++ editor / IDE is exciting,
> because it means being able to reuse clang's parser and related functionality
> instead of having to roll our own.
> >
> > As mentioned in Doug's post, there is an "LSP4E" project underway [4] that
> allows Eclipse to act as an LSP client, with the functionality integrated into the
> Generic Editor [5].
> >
> > Finally, to connect the dots, Marc-André Laperle has written an "lsp4e-cpp"
> plugin [6], that allows LSP4E to connect to Clangd, and thereby get Clangd-
> powered C++ editor functionality in Eclipse.
> >
> > All of these projects are currently in a fairly early stage of development.
> However, I'm thinking ahead about what will be a good way to get this
> functionality in front of users, and how - if at all - lsp4e-cpp should be
> integrated with CDT.
> >
> > I can think of a few options:
> >
> > 1) Not integrated with CDT.
> >
> > In this scenario, users wanting to take advantage of Clangd
> > in Eclipse would install Clangd, LSP4E, and lsp4e-cpp (which
> > would then need to have its own releases and its own update
> > site), and would not need to install CDT.
> >
> > 2) Integrated into CDT as a new project type.
> >
> > In this scenario, lsp4e-cpp could be part of CDT. A user
> > would install Clangd, LSP4E, and CDT, and create a new
> > kind of project, say "C/C++ LSP Project". Source files in
> > that project would open up with the Generic Editor, and
> > use the LSP/Clangd functionality.
> >
> > 3) Integrated into CDT, usable by existing projects
> >
> > In this scenario, users could choose to open files in
> > their existing projects with either the current C++ editor,
> > or the Generic Editor, which would then use the LSP/
> > Clangd functionality. This has the advantage of allowing
> > users to start benefiting from the functionality in their
> > existing projects.
> >
> > I believe this is more or less what happens right now
> > if you install Marc-André's plugin.
> >
> > 4) Integrated into CDT's C++ editor
> >
> > In this scenario, rather than using LSP4E's integration
> > with the Generic Editor, we could integrate the LSP-
> > powered functionality into the current C++ editor itself.
> > (For example, for code completion, we could have a new
> > completion proposal computer that uses the LSP). We
> > could probably still reuse large parts of LSP4E to achieve
> > this.
> >
> > This option would involve the most work, but it would have
> > the advantage of allowing users to transition to LSP
> > without losing functionality. For example, currently LSP
> > does not have semantic highlighting support, but our C++
> > editor does. With this approach, users could continue to
> > enjoy semantic highlighting in our C++ editor, while
> > benefitting from other things (like code completion) powered
> > by LSP in the same editor.
> >
> > Does anyone have thoughts about which of these integration options
> would be a good choice? There may, of course, be other options I haven't
> considered as well.
> >
> > Regards,
> > Nate
> >
> > [1] https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg31710.html
> > [2] https://clang.llvm.org/extra/clangd.html
> > [3] https://github.com/Microsoft/language-server-protocol/
> > [4] https://projects.eclipse.org/projects/technology.lsp4e
> > [5] https://www.eclipse.org/eclipse/news/4.7/M3/#generic-editor
> > [6] https://git.eclipse.org/r/#/c/101857/
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/cdt-dev