VSCode Extension

Hey gang,

As I’ve mentioned earlier, the Eclipse CDT project is pivoting to produce both Eclipse plug-ins and VS Code extensions to support our community. clangd is a core of that strategy.

I was just wondering about the state of the vscode extension hosted in clangd. It appears to be published regularly to the Marketplace. If we are to reuse it in the CDT vscode extension, we’ll probably need to make API changes to it to allow us to change configuration a bit. What is the release strategy for it? Where are builds and testing done so we can monitor the health of our changes (i.e. is there a CI machine that builds it?).


Hi Doug,

The state of the world is pretty primitive, releases are by hand and any testing is manual and ad-hoc. (Unless something has changed recently that i missed)

That said, the extension is a small wrapper around the basic vscode LSP client. There’s <100 lines of real code, mostly implementing the status extension.

So what kind of reuse are you looking for?

  • want to extend the client, and pick up any new additions?
  • want to extract some common code so it can be tested/maintained together?
  • looking to share release/validation infrastructure, but not necessarily extension code?
  • something else?

Cheers, Sam

Up until now, we’ve just had our own language server client but would like to eliminate duplication. I’m just trying to figure out how.

As an example, the CDT vscode extension will download a clangd binary so the user doesn’t need to worry about that. Our users are mainly gcc users who don’t necessarily, and likely don’t, have clang installed. So we’ll need to install what they need for clangd to work. One API we would need is to set the location where we installed clangd so that when vscode starts up the language server, it’ll start the one we installed unless the user overrides that. I’m not even clear how to do that properly given the start sequence of the extensions.

We’ll also be generating compile_commands.json files for systems that don’t do that natively. And eventually we’ll need to manage build configurations where users target the same project on multiple targets. So we’ll need to let clangd know when those things change.

In addition, we’ll share the same features with our Eclipse IDE plug-ins as we migrate to clangd using Eclipse’s LSP4E. Would be great if we can keep the feature sets in sync even if we can’t use the same code between the two. Licensing could get interesting as we’re EPL since we’re an Eclipse project and the clangd vscode extension is MIT. Should be able to mix but need to do it carefully.

Anyway, thanks for the info. I guess for now, I’ll keep an eye on things and we’ll see if we run into problems as we put this together.