Our Carbide.c++ tools for Symbian OS development have spent the last several months in front of hundreds of people in our beta program. Now it's time to wrap things up and get ready to release. For this update we moved to version 3.3.1 of the platform and 4.0.3 of CDT, added lots of little enhancements, fixed hundreds of bugs, and posted about a dozen patches for CDT and the platform.
People really like the improvements to the indexer and code navigation tools in CDT and gave us lots of feedback on where they could be improved, especially support for C++ templates. All the positive response was tempered by continued frustration with the way projects have to be organized so we are still looking for solutions to that problem.
Symbian OS projects have their own build system and our support for it is now better integrated into the new CDT project model. Our debugger now takes better advantage of the contextual launch support in Eclipse 3.3 and we added a view for managing and debugging lots of executables.
Opening up our bugzilla to everyone in the beta program has really been helpful and brought our team a little closer to everyone using the tools. Making our nightly builds available has let us get fixes out to people fast for quick validation. Overall I think running our beta program much like an Eclipse project has let us make the right kinds of changes faster than we have before.
Thursday, January 24, 2008
Monday, November 26, 2007
Open Carbide.c++ beta begins
Back at the CDT summit in late September someone asked me if I had gone into hiding. Not exactly, but along with the rest of the Carbide.c++ team here at Nokia I've been focused on getting a new update (v1.3) out to our beta community. We finished the first beta drop just before the Thanksgiving break so it's now out there for anyone to try out.
For this update to our C++ tools for Symbian OS we moved to a new version of the platform (3.3.x) and CDT (4.0.x). We are also reinventing our development process to be more agile and responsive with a lot of the inspiration for this coming from the Eclipse community: We're now running our beta program through a google group that is open to anyone who asks to join. Our internal bugzilla has been opened up so that everyone can use it to report and track bugs. We'll be doing periodic beta releases that have some testing behind them and also publishing the last week's worth of auto-tested nightly builds. The nightly builds will give us a way to validate bug fixes and get immediate feedback from the thrill seekers who don't want to wait for the next beta.
So far we're off to a good start with a couple hundred downloads and a couple dozen new bugs, mostly from people in the rest of the world that wasn't focused on turkey and football last week.
For this update to our C++ tools for Symbian OS we moved to a new version of the platform (3.3.x) and CDT (4.0.x). We are also reinventing our development process to be more agile and responsive with a lot of the inspiration for this coming from the Eclipse community: We're now running our beta program through a google group that is open to anyone who asks to join. Our internal bugzilla has been opened up so that everyone can use it to report and track bugs. We'll be doing periodic beta releases that have some testing behind them and also publishing the last week's worth of auto-tested nightly builds. The nightly builds will give us a way to validate bug fixes and get immediate feedback from the thrill seekers who don't want to wait for the next beta.
So far we're off to a good start with a couple hundred downloads and a couple dozen new bugs, mostly from people in the rest of the world that wasn't focused on turkey and football last week.
Saturday, September 29, 2007
"I've got Barbies in my suitcase"
I took a break from Carbide 1.3 development to attend last week's CDT summit in Ottawa. I wasn't sure what to expect going in but after people presented their prospective contributions we ended up with an exciting list of new work planned for CDT 5.0 next summer. There are a series of improvements to existing features like the parser, code navigation tools, editor, project model etc., and some new things like a class browser and the integration of the device debug project's DSF framework.
We also talked about EFS support in CDT and Doug is going to explore using this to allow projects to include an arbitrary set of files from anywhere in the file system. Not sure if it will work yet but this is a big issue for Carbide users and anyone else doing C/C++ so I'm encouraged by any attempt to fix it.
I got to share a lot of the feedback we have received from Carbide users and demo our new Executables View. The debug support in CDT is in transition and we had a good series of discussions about how to proceed. I've been exploring moving Carbide's debugger to use DSF and it was great to be able to talk to Pawel Piech (DSF lead) and the team from Ericsson doing the gdb/mi reference implementation. Pawel endured some good natured harassment about the current look of the DSF launch icon
which finally prompted his shocking but unverified confession about the contents of his luggage.
On the flight back to Austin I noticed a guy a couple rows up running Eclipse on his laptop (It stood out in the sea of solitaire games, powerpoint slides and action movies on the other screens). Turned out to be Chris Aniszczyk so I finally got to meet and chat with him during the layover in Chicago.
Again I was impressed by the professional, pragmatic, and friendly bunch of people in the CDT community. Thanks to Doug, the QNX team, and the Eclipse folks for hosting the summit.
We also talked about EFS support in CDT and Doug is going to explore using this to allow projects to include an arbitrary set of files from anywhere in the file system. Not sure if it will work yet but this is a big issue for Carbide users and anyone else doing C/C++ so I'm encouraged by any attempt to fix it.
I got to share a lot of the feedback we have received from Carbide users and demo our new Executables View. The debug support in CDT is in transition and we had a good series of discussions about how to proceed. I've been exploring moving Carbide's debugger to use DSF and it was great to be able to talk to Pawel Piech (DSF lead) and the team from Ericsson doing the gdb/mi reference implementation. Pawel endured some good natured harassment about the current look of the DSF launch icon
which finally prompted his shocking but unverified confession about the contents of his luggage.On the flight back to Austin I noticed a guy a couple rows up running Eclipse on his laptop (It stood out in the sea of solitaire games, powerpoint slides and action movies on the other screens). Turned out to be Chris Aniszczyk so I finally got to meet and chat with him during the layover in Chicago.
Again I was impressed by the professional, pragmatic, and friendly bunch of people in the CDT community. Thanks to Doug, the QNX team, and the Eclipse folks for hosting the summit.
Tuesday, June 12, 2007
Usability and CDT 4.0
When we first began developing our C++ tools we wanted to see what usability issues developers would face so we ran a series of testing sessions with people new to Eclipse, people who had used Eclipse for Java development, and people developing with Visual Studio.
The bug 154280 has more details but my story here is that the issues on the front line have been addressed in Europa.
When we asked people to build a newly created project they looked for a build button in the toolbar. (The platform has a Build All button but it's not easily identifiable and it builds all).
Now CDT 4.0 includes a Build Project button that builds the active configuration of the selected project and has a menu that lets you build any of the other ones.
When we asked people to debug their project they naturally hit the Debug button and ended up getting confused by the Launch Configuration dialog.
Now CDT 4.0 takes advantage of the new debug platform support for contextual launching: Hitting the debug button now does what people expect, launching a debug session for the selected project and using the launch shortcut to ask for any settings it needs along the way.
We're tracking lots of other usability issues from C/C++ developers but I'm pleased these two big out of the box problems are fixed in Europa.
The bug 154280 has more details but my story here is that the issues on the front line have been addressed in Europa.
When we asked people to build a newly created project they looked for a build button in the toolbar. (The platform has a Build All button but it's not easily identifiable and it builds all).
Now CDT 4.0 includes a Build Project button that builds the active configuration of the selected project and has a menu that lets you build any of the other ones.When we asked people to debug their project they naturally hit the Debug button and ended up getting confused by the Launch Configuration dialog.
Now CDT 4.0 takes advantage of the new debug platform support for contextual launching: Hitting the debug button now does what people expect, launching a debug session for the selected project and using the launch shortcut to ask for any settings it needs along the way.We're tracking lots of other usability issues from C/C++ developers but I'm pleased these two big out of the box problems are fixed in Europa.
Monday, May 14, 2007
Would you like JDT with that?
In a recent conversation in bugzilla someone asked if it was common for people using CDT to also have the JDT installed. The short answer is "yes" but that's not always because they are developing in Java as well as C++.
When people start with our Carbide.c++ they run a branded installer like you get with most Windows apps and you get an entry in the Start menu etc. We install a JRE and a bunch of Eclipse features but not the JDT. People focused on C++ development didn't want to see "all the Java stuff" so we left it out.
But people who are also doing Java development (sometimes developing plug-ins for Carbide) or who already have Eclipse configured with their favorite plug-ins can just take our Carbide features and merge them in. Corporate IT people often like to have a standard version of Eclipse that usually includes the JDT since it is seen as part of the base platform. Also some plug-ins out there assume the JDT is present and will not work correctly if it isn't. So we've got to assume there is a good chance the JDT will show up at some point.
I recall one of the sessions at EclipseCon this year where the presenter was showing Eclipse with all of the Europa plug-ins (and maybe some others) installed. The UI was an impressive jumble of widgets and completely confusing. Someone said something about capabilities being useful but added that "no one uses them."
I was surprised as we use capabilities extensively to keep the user experience focused on C++ development when people are using Carbide, mostly by hiding CDT UI that isn't used when developing apps for Symbian OS. At some point I'll have to see if we could start including the JDT but keep the UI subdued unless you start working with Java projects.
When people start with our Carbide.c++ they run a branded installer like you get with most Windows apps and you get an entry in the Start menu etc. We install a JRE and a bunch of Eclipse features but not the JDT. People focused on C++ development didn't want to see "all the Java stuff" so we left it out.
But people who are also doing Java development (sometimes developing plug-ins for Carbide) or who already have Eclipse configured with their favorite plug-ins can just take our Carbide features and merge them in. Corporate IT people often like to have a standard version of Eclipse that usually includes the JDT since it is seen as part of the base platform. Also some plug-ins out there assume the JDT is present and will not work correctly if it isn't. So we've got to assume there is a good chance the JDT will show up at some point.
I recall one of the sessions at EclipseCon this year where the presenter was showing Eclipse with all of the Europa plug-ins (and maybe some others) installed. The UI was an impressive jumble of widgets and completely confusing. Someone said something about capabilities being useful but added that "no one uses them."
I was surprised as we use capabilities extensively to keep the user experience focused on C++ development when people are using Carbide, mostly by hiding CDT UI that isn't used when developing apps for Symbian OS. At some point I'll have to see if we could start including the JDT but keep the UI subdued unless you start working with Java projects.
Monday, May 7, 2007
Structuring C++ Projects in Eclipse
We’ve been struggling with how to represent C++ projects in Eclipse so I thought I would share our story in case anyone can offer any better suggestions:
It’s common for developers to already have their code organized something like this:
/Source/Projects/CPPProjectOne/src – project one specific code
/Source/Projects/CPPProjectTwo/src – project two specific code
/Source/Projects/CPPProjectThree/src – project three specific code
/Source/Projects/Common/src – source common to all CPP projects
We can not copy the source files to another location or move anything around, we have to work with them exactly where they are in the file system. Since for each project we call a custom make builder that doesn’t depend on anything in Eclipse the main thing we want our Eclipse projects to do is contain as much of the code as possible so that all of the splendid IDE features work correctly.
Our first thought was to put the Eclipse projects in the workspace and then stuff them with linked resources to the actual source files and folders. That seemed like a great fit for linked resources and would be fairly straightforward to do. However we discovered that linked resources are not really first class citizens in the workspace: to begin with they don’t work with version control (41929) so we had to abandon that idea.
Our next try was to just locate the Eclipse project and it’s source root where the cpp project’s code actually lives. When we import a cpp project’s make file we can look at the included sources and determine a root location that covers all the files. So using the above example CPPProjectOne’s source root would be /Source/Projects. This works OK, we end up with an Eclipse project that lives at /Source/Projects/.project and includes resources for all of the desired files (plus lots of other stuff too).
The trouble begins when I want to work with CPPProjectTwo at the same time. I find that it has the same common source root location as CPPProjectOne, but I can’t put a second Eclipse project there as a .project file already exists in that location.
The best work around we have been able to think of for now is to have the second project use a more narrowly scoped source root, in this case it could use /Source/Projects/CPPProjectTwo. But that will leave other files it uses, like those from /Source/Projects/Common/src, out of the project.
If we could either put more than one Eclipse project in the same location or tell a project to use something other than its location as a source root (78438) then we could accommodate any number of projects. Or if linked resources worked better we could use those. Just now we’re stuck telling people to try the work around but we need to determine what direction to pursue longer term so we can make this work the way people expect.
It’s common for developers to already have their code organized something like this:
/Source/Projects/CPPProjectOne/src – project one specific code
/Source/Projects/CPPProjectTwo/src – project two specific code
/Source/Projects/CPPProjectThree/src – project three specific code
/Source/Projects/Common/src – source common to all CPP projects
We can not copy the source files to another location or move anything around, we have to work with them exactly where they are in the file system. Since for each project we call a custom make builder that doesn’t depend on anything in Eclipse the main thing we want our Eclipse projects to do is contain as much of the code as possible so that all of the splendid IDE features work correctly.
Our first thought was to put the Eclipse projects in the workspace and then stuff them with linked resources to the actual source files and folders. That seemed like a great fit for linked resources and would be fairly straightforward to do. However we discovered that linked resources are not really first class citizens in the workspace: to begin with they don’t work with version control (41929) so we had to abandon that idea.
Our next try was to just locate the Eclipse project and it’s source root where the cpp project’s code actually lives. When we import a cpp project’s make file we can look at the included sources and determine a root location that covers all the files. So using the above example CPPProjectOne’s source root would be /Source/Projects. This works OK, we end up with an Eclipse project that lives at /Source/Projects/.project and includes resources for all of the desired files (plus lots of other stuff too).
The trouble begins when I want to work with CPPProjectTwo at the same time. I find that it has the same common source root location as CPPProjectOne, but I can’t put a second Eclipse project there as a .project file already exists in that location.
The best work around we have been able to think of for now is to have the second project use a more narrowly scoped source root, in this case it could use /Source/Projects/CPPProjectTwo. But that will leave other files it uses, like those from /Source/Projects/Common/src, out of the project.
If we could either put more than one Eclipse project in the same location or tell a project to use something other than its location as a source root (78438) then we could accommodate any number of projects. Or if linked resources worked better we could use those. Just now we’re stuck telling people to try the work around but we need to determine what direction to pursue longer term so we can make this work the way people expect.
Monday, April 16, 2007
Carbide 1.2 is Out the Door
We've completed the final build for Carbide 1.2 so I can come up for air now. Carbide 1.2 is using Eclipse 3.2.1 and a modified version of CDT 4.0M5. Taking the risk on a pre-release version of CDT has worked out well: the code navigation features bring us much closer to what people expect and we've seen few problems. Over the last couple months our team has been helped by a great beta group of several hundred people testing Carbide in a production environment with lots of sizable real world projects. This has been illuminating and occasionally humbling as people told us what we had to deliver to pull them away from their current C++ development environment. We couldn't get all of it into this release and so we're left with a lot of raw feedback to distill into specific fixes and enhancements for next time.
Now I need to move ahead with work on my CDT bug list and planning for the next Carbide release which will use Eclipse 3.3 and the final version of CDT 4.0. How did it get to be mid April already?
Now I need to move ahead with work on my CDT bug list and planning for the next Carbide release which will use Eclipse 3.3 and the final version of CDT 4.0. How did it get to be mid April already?
Subscribe to:
Posts (Atom)
