Monday, May 16, 2011

Update on Carbide, EDC, Symbian, Nokia

Time for an update on the state of Carbide, the Eclipse Debugger for C/C++ (EDC), Symbian, and Nokia. As usual all comments and analysis are my own.

We finally shipped Carbide 3.2 to the public! This is the first publicly available 3.x version of Carbide and the first new version seen outside of Nokia in over a year. It includes support for a new build system, a brand new on-device debugger built on top of EDC, and lots of usability improvements. The delay was a result of one of the many iterations of Nokia's strategy over the past few years: for much of 2010 and until February 11th of 2011 we were telling developers that our mobile platform was the Qt app framework, not Symbian. The Qt folks were busy building their own IDE (Qt Creator) and so it was thought that developers would be confused if they had Carbide available as well. So Carbide was designated a "platform tool" only for use by Nokia's thousands of internal developers.

Then on February 11th our new CEO announced that Nokia would be using Microsoft's Windows Phone 7 software in the future and Symbian would be phased out over the next couple years. So our team has ended up in a strange position: we need to keep Carbide up to a high standard to support Nokia's continuing Symbian efforts but we know the plug will be pulled at some point, probably within the next year. Nokia has built in some flexibility for it's Symbian roadmap and arranged a soft landing by working out a deal to transfer 3000 people to Accenture at the end of this year. Accenture will then contract us back to Nokia to do the remaining Symbian work.

Our team's chief contribution to the Eclipse community over the past 24 months has been the Eclipse Debugger for C/C++ (EDC), part of the CDT project. Faced with the need for a new C/C++ debugger for Carbide and unhappy with any of the available options we designed and built one from the ground up. But the ground was already pretty rich: we leveraged all the work done in CDT's Debug Services Framework (DSF), used the CDT language parser for expression support, and relied on the Target Communications Framework (TCF) for low level debug services.

The first version of EDC shipped with Helios but it was pretty raw as we hadn't yet shipped a Carbide product using it. Indigo EDC is a big improvement in stability, performance, and feature set and we got to fix a number of things we didn't get right on the first attempt. The two reference debuggers provided with EDC (Windows & Linux) still aren't near production quality but are great for introduction and testing and provide a good example of how to build a debugger around EDC.

As we developed EDC we found other tools people interested in the idea and it reflects valuable contributions from the CDT community. As Carbide winds down I hope it continues to offer some value to anyone moving beyond their legacy debugger. I'd like to continue improving it and the rest of CDT but that awaits a volatile future.

1 comment:

zzhou said...

> Indigo EDC is a big improvement in stability, performance, and feature set and we got to fix a number of things we didn't get right on the first attempt. The two reference debuggers provided with EDC (Windows & Linux) still aren't near production quality but are great for introduction and testing and provide a good example of how to build a debugger around EDC.

I am to create a new debugger that integrates with CDT. Currently we have a custom version of the GDB (there are a couple of new commands, different data, etc.
Do you think it would be better to try and leverage the EDC? We will be building on top of Indigo.