Bringing Indigo to C and C++ Devs

CDT in Eclipse Indigo

Jessica Thornsby
CDT-in-Eclipse-Indigo

“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.

Author
Comments
comments powered by Disqus