Bringing Indigo to C and C++ Devs

CDT in Eclipse Indigo

Jessica Thornsby

“The Eclipse contributors know what needs to be done and we just do it!”

Although it’s well-known for its Java projects, the Eclipse Release Train shipped with version 8.0.0 of the CDT project, which provides a C and C++ Integrated Development Environment based on the Eclipse platform. In this interview, we speak to long-time CDT committer, and project lead Doug Schaefer, on CDT’s latest release and the ongoing challenges of adapting Eclipse for C and C++ developers. He also shares his thoughts on the headline-grabbing Orion project, and how the annual Release Train might look in the future.

JAXenter: Eclipse Indigo comprises of 62 projects and 46 million lines of code. This is a huge number and for sure a great achievement for the Eclipse Foundation. What are your personal highlights in Eclipse Indigo?

Doug Schaefer: As with every train release, I’m always impressed by how all these projects come together and work as one team, working for a common goal. Everyone who works on Eclipse is proud of being a part of such a special movement in open source. What’s even more impressive is the ability to bring this all together without the need of an army of program managers to co-ordinate things. The Eclipse contributors know what needs to be done and we just do it. That just speaks to the strength of the people we have in the community.

JAXenter: The CDT project is part of Indigo in version 8.0.0. What´s new in the Indigo version of CDT?

Doug: The biggest new feature in CDT 8.0 is the graduation of our static code analysis framework called Codan into the main CDT feature. Codan supports checking of code as you type, presenting both syntax and logical errors, and offers quick fixes to resolve some of those errors. We’ve  always been chasing JDT for feature richness and with Codan, I think we’ve almost caught them.

We are also working hard on supporting the complex debug scenarios that result from today’s multi-core computer systems. Scalability is the biggest issue when trying to work with multiple debug contexts at the same time and we have some features in the debug perspective to help the user work in those environments and to leverage new features supporting those environments with gdb, the GNU debugger.

JAXenter: How would you describe the situation regarding the user adoption of the CDT project?

Doug: User adoption of the CDT still remains strong. We’ve been averaging around 600,000 downloads for each release which is an impressive number given where we started. There is a strong need in our industry for a C/C++ IDE that supports development beyond Windows and Mac and the CDT is the IDE of choice for embedded systems developers, and we’re gaining a lot of new users developing for Linux. I’m pretty proud we’ve been able to put together a good IDE that so many have found useful.

JAXenter: The typical use case for the Eclipse Framework was originally JDT, the IDE for Java Developers. Is it still a challenge for CDT to adapt Eclipse for C/C++ developers?

Doug: It still is a challenge for C/C++ developers to adopt Eclipse. We’ve always struggled with assumptions made in the Eclipse platform that make sense for Java, but where C/C++ projects demand more flexibility. The great news is that we’ve been able to get committers who have been able to contribute to the Eclipse platform as well. The flexible resources project that we started
as part of e4 has been adopted back into the 3.x main line and we’ve added some features in Indigo to the build system that will make it easier for us to manage build configurations. We hear the troubles our users are facing and we’re working hard to address those, no matter where the problems exist in the Eclipse IDE stack.

JAXenter: What is your opinion on Orion, the new browser IDE at Eclipse?

Doug: I think Orion is an exciting new direction for Eclipse. We’ve been talking about a browser based IDE for a couple of years now and it’s great to see it start to materialize. But I still reserve judgement over how useful it will be as an IDE. So far, we’ve seen it as a great editor for JavaScript and has a nice integration with source control systems. For web development, where
that’s all you need, I think it will be successful.

But I don’t see that web based IDEs will replace thick clients any time soon, if ever, especially with C/C++ developers. They work with a large collection of tools both in the IDE and on command lines, especially the command line. We have a hard enough time getting them to use IDEs let alone putting a web browser between themselves and their code. And I’m not certain that the web paradigms of REST and web pages is a natural fit to the workflows we are trying to support. It’s like we are taking a solution and trying to make it fit our problem.

No, I have a grand vision of advanced visualizations and tight integration between code, debugging, and analysis tools that are much easier to implement if we have full control over the UI. You give up some of that power going to the browser. But there are things we can learn from it that we shouldn’t ignore, especially the ease of management that hosted tools offer large organizations. I’m sure those organizations are watching closely too and I interested to see how far they go.

JAXenter: In your blog, you wrote that the Eclipse Release Train is dependent on only a few people who care about things like site aggregation or EPP Builds. You are looking for a better system where anyone can fill the shoes of another. How would this system look?

Doug: Yes, we have great people who are key to getting the train built and brought to the community. Every project has them and they have a lot of knowledge about the tools and processes used to make the release train happen. I’d like to see us achieve the ability for anyone, inside or outside of Eclipse, to be able to build all the artifacts that go into the train. And I think we finally have the tools to make that happen.

First of all, we need to continue the move of projects to git. Distributed source control gives anyone the ability to have access to all the source that goes into Eclipse and to make any changes to it that they need to satisfy their downstream. These people also need an easy way to build all
the artifacts, and Maven with the help of the Tycho plug-ins for building Eclipse artifacts is a great choice to meet that need. So as long as the source repositories are available or cloned somewhere, anyone can reproduce the release train with a simple, if not a single, command.

We’ve done our part for the CDT project moving to git and Maven right after the Indigo release. I see a lot of projects thinking of doing the same. I’m pretty excited that we’ll get there, possibly even for Juno.

JAXenter: What are the next steps for CDT in the upcoming Juno Release Train?

Doug: After each train release, I always feel we’ve reached a milestone that the CDT project is finally mature and no new features are needed. The community always surprises me and we continue to grow instead. I think that will be true for Juno as well. We have a lot more things we can add for code analysis and multi-core debugging. I’d also like us to be in a better position to support the mobile platforms such as Meego and Android and we’ll need to clean up our build system for that. And I’m also seeing some renewed activity around Objective-C support and I’m hoping we can finally be in a position to support iOS and Mac developers who want to use Eclipse. And there are a few of them.

Inline Feedbacks
View all comments