[cdt-dev] CDT Vision and 5 Year Plan

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

Hey gang,

For those who were at the summit yesterday, a huge thank you for helping inspire our group and start to put together a vision for the future of CDT and a 5 year plan to get there.

For those who weren't there, there is a good set of minutes on the Summit page here: https://wiki.eclipse.org/ECE_EmbeddedToolsSummit2018

To summarize and to ask for your engagement, here's what we came up with. We'd love your input and any suggestions you may have to help make sure this is a community driven vision that each of you own.

In recent years, we've seen a new architecture for IDEs that helps us all share in the work of some important common pieces.

That starts with the Language Server Protocol where we are seeing excellent progress on a few fronts with the C++ Language servers, clangd, cquery, and ccls. Clangd seems to have the most industry momentum and is what I am concentrating on. But whichever way we go it is clear that we have an evolutionary path that will allow us to leverage all the great work going into clang and clang related tools in the CDT.

In our discussions this week, we can see this also extends to the Debug Adapter Protocol which provides a common way to integrate debuggers with our IDEs. And there are other initiatives out there including Bernd's trace server protocol and there is a talk this week on a graphical modeling protocol. It is clear that this componentization of IDE services that can be shared will change IDEs and enable choice for our users picking the front ends they feel most comfortable with while enjoying all the great features that are shared with each.

To ensure Eclipse CDT has a role in that future, we are going to start working toward evolving CDT to take advantage of these services.

Work has already begin with LSP thanks to Nate and our GSOC student. We will continue that effort and work with the upstream language servers, forking if necessary, to ensure feature parity with our current set of language services.

Jonah has begun work on Debug Adapter support for Eclipse as part of the LSP4E project. We will evolve that to feature parity with CDT's debug services. We will also create a debug adapter for GDB in the CDT project that can be used by any IDE and will plug into the Eclipse Debug Adapter host. We also will create a Visual Studio Code extension to support it and will work with the Theia team on how best to provide it there as well.

We had a great discussion on the evolution of Managed Build led by William from Renesas. This will be a great opportunity to rid us of the pain of the current managed build using a more modern approach. I also challenge that effort to see if we can take this new capability and reuse it with other IDEs as well.

So essentially, the vision is to have Eclipse CDT as a peer to Visual Studio Code and Theia and any other IDE that wants to leverage the open source components we create. We have a ton of expertise and we have a chance to lead this new world of C/C++ IDEs. And we will.

Now, the move in this new direction will have an impact on downstream consumers of CDT. This is where we need to reach out and start spreading the news that CDT will change drastically over the next few years. It is up to them to manage the impact on their products. In particular, we will be deprecating the existing managed build system as well as the Debug Services Framework. The LSP work will eventually deprecate everything from the CDT parsers and editor on up. The new technologies are much thinner and easier to maintain and leverage the work of a larger community. As things are now, we are short staffed to support these legacy services while also working on the new. We will need contributors to keep those services around. If not, we'll archive them as we did with the CDI debug framework.

I am extremely excited by this initiative. Hopefully this will help grow excitement in the greater community in what we do especially as we move in new directions and get in front of new groups of users.

More as we go. Again, we'd love and need your feedback.
Doug.