Monthly Archives: February 2009

Subversive vs. Subclipse

One of the most common Google searches I see in my Feedjit log is from people looking for help in the whole Subversive versus Subclipse debate. It has always dumbfounded me why we have two efforts building Eclipse team providers for Subversion. But I’ve long given up on fighting that battle.

So as I start to dive into the code for qemu, I found myself in need of making that choice again. Some would say go with Subversive since it’s an Eclipse project. I would, but they are mired in provisioning hell with a key component for making it work being on another site due to licensing/IP reasons. That didn’t turn me on much so I’m going with Subclipse.

And so far so good, but I’ve only just checked out the repository. We’ll see how it goes if I need to make any patches, and as I keep updating. But my hope is that as it has aged, all the issues I saw a couple of years ago have been addressed.

My heart is still with distributed version control and git in particular. And there is discussions on the qemu list about moving to git. And in particular, I’m very interested in how these team providers work with the CDT and how they work with the changes were doing for e4 on the IResource front. And it’s pretty clear that these plug-ins, no matter what version control system they target, need to work well to keep our users and customers engaged.

CDT 6.0 M5 is Available, BTW

I’ve been “nose to the grindstone” since the holiday break getting our Wind River Installer out the door, twice. But the good news is that the CDT contributors have been very busy working on CDT 6.0 while I wasn’t looking very hard. I have been waiting for the C/C++ IDE Package for M5 to be built. In the meantime, we do have the bits up on the CDT Galileo update site for you to try. Just download the Eclipse Platform or SDK 3.5M5 and add the following URL as an update site:

Most people will want the “Tools” feature in the “Main” group, which will give you everything you need to work with the gnu toolchain. And yes, the features say 5.1.0, but we’re tricking the API tooling with that to keep track of API changes. We’ll be 6.0 when we go out the door in June.

I’ve actually been using CDT 6 for some technical investigations I’ve been doing lately, the qemu source being one of them. One of the biggest issues with the CDT that we’ve been fighting forever has been taking projects that have been developed without an IDE, that don’t have any real structure to them, bringing them into the CDT, and having our indexer parse and create useful search information for them. And this is especially bad if we can’t figure out the include paths to find the header files needed to parse properly.

One common pattern we have noticed with the include path was where all the user specified include paths were actually folders in the workspace. Everything else came from the built-in include path. At the very least, if we could search the workspace when looking for header files that were unresolved, we could probably resolve them.

Well in CDT 6.0M5, that functionality if finally there (thanks, Markus!) and it works superbly! Many of the unresolved headers I saw in this one project I was looking at, which targeted many different OS’s, were magically resolved, and features like Open Definition (F3) worked great. Sure, if you have multiple header files with the same name in your project, we may pick the wrong one to resolve, and there will still be issues if you don’t specify external include paths, but it’s huge step forward for CDT usability.

There are other interesting things in M5, including the Debug Services Framework which has moved from the Device Debugging project to the CDT and should become our “official” debug framework over time. You’ll notice the major issue we have with having two debug frameworks when you go to launch (double the launch configs 🙁 ), but we are working on a solution to that.

We’re still making great improvements to the CDT as we go. Most of them are under the hood as the feature set we have is working quite well already. And there are still things to clean up, like our managed build system and the underlying build model and the need to integrate that with our debug models. But I know I’m a happy CDT customer myself, and I hope you get a chance to try out CDT 6.0 M5 and give us your feedback.

Eclipse in the Clouds?

I’m not going to say much with this one. I’ll just refer you to the comments people are adding to Boris’s blog entry on his work with Mozilla to get an experimental IDE running in a browser with an Eclipse-based server back-end. Is this what developers working in the embedded and desktop space are asking for? Not that I’ve heard. And neither do a number of the commenters on Boris’s article. Some of them are putting it in much prettier words than I could say without getting into trouble…

That’s why it is so critical for those of us in the Eclipse community who support such users to make sure Eclipse continues to work well and to improve in the areas that cause them pain. Is the future of enterprise development so different from desktop and embedded that it requires such radical architectures? Maybe so. If that’s true, we need to hold our ground and ensure we don’t get dragged down a path we can’t be going.

An ARM on Family Day

It’s “Family Day” here in Ontario, Canada, and while my one son is over at his buddy’s house and my other son is watching game trailers and my wife is out for lunch with the girls, I’m sitting here enjoying the day off. I’m sure we’ll do something family-ish later today…

Anyway, I just read about TI’s new family of chips, the OMAP4. The big news is that this is the first time TI has jumped on ARM’s multi-core bandwagon and the mixture of parts going into these SOCs is quite impressive. You have PowerVR’s venerable SXG OpenGL ES 2.0 engine, image processing, and enough power to play 1080p video. As the TI guys says in the article, this type of architecture really will start to blur the lines between smartphones and MIDs (and even makes me wonder about the set-top box market). It looks like we’ll be seeing some pretty exciting products ahead.

Speaking of TI, I’m still looking at the BeagleBoard community-based development board kinda thing. The more I look into what the community is doing with it, I really see it’s potential as a vehicle for learning embedded development. But I’m cheap, so my attention turned towards whether the qemu emulator could emulate the BeagleBoard so I can run it on my laptop. And apparently someone is working on it. But then I started doing the math. How much is my time worth? Versus forking out the $300 or so to get set up. Makes me think…

Mucking around with all this has led me back to my EclipseCon tutorial on integrating a cross-compiler toolchain for the CDT. I really want to show how easy it is to get up and running with qemu and a cross-compiler and the freely available embedded Linux run-time goodies all under the CDT as the IDE. And given all the hype about ARM and mobile, I think I’ll go with ARM as the target CPU. Should be a fun 4 hours, which should be plenty of time to get at least a hello world running. I can’t wait and I really hope you can make it too.


Slashdot pointed me to this article by Bruce Parens aimed at clearing some of the air around using GPL and LGPL and commercially licensed product on the same device. Of course, the summary of the article is “Check with your lawyer” as it should be. But I hope it alleviates fears over the FSF licenses that I know people have.

I especially like the description of the motivation that open source developers use to license their software. BSD is a “gift” software license. The developer is giving it to you as a gift, do with it as you wish, just give him some of the credit. LGPL is “non-gift”. And I get it. They essentially don’t want you using their stuff for free unless you help with it. And then you have GPL, which falls into the category that they just don’t want you using their stuff for free, unless you’re doing your stuff for free too. This categorization puts a little bit of a human face on it, and I appreciate that.

This also made me think about our situation at Eclipse. It’s very difficult to get third party software approved at Eclipse. I’d love to be able to host the GNU tool chain binaries along with the CDT to help new developers get started. Now, I am not a lawyer, but Bruce’s article doesn’t mention restrictions on distributing binaries, only the run-time requirements. Maybe I’m missing something there, and maybe lawyers are reading more into the license than what I see. So be it, they’re professionally responsible for their opinions, I tend not to be.

But there is no mistaking it. Despite whatever legal issues surround open source software, it’s popularity can’t be denied, especially in the embedded world.

Beagle Board and Eclipse Distros

We had a meeting a few days ago amongst interested parties in an Eclipse IDE distribution for embedded. The idea would be to do something like I’m doing with Wascana which is supposed to make it easy for developers using open source tools, students especially, to get them up and running on Windows, and in turn showcase the features of the CDT in that environment. The idea of doing this for embedded would be to do the same for embedded systems developers and to show case the features of the DSDP project at Eclipse as well as CDT’s embedded development support.

One thing I think we noticed quite quickly is the diversity of the embedded community at Eclipse. We have Web services applications for embedded, we have J2ME Java for embedded, we have deeply embedded systems like microkernels and DSPs that have no OS per se, and, of course, we have the more traditional RTOS systems. I think it’ll be hard to showcase Eclipse support for all these things in one distro, and maybe it deserves it’s a few such distros, or maybe we have RTOS versus not RTOS. It’s an interesting initiative and I’m excited to see where it goes.

One of the platforms that came up in the meeting was the Beagle Board. Checking out their web site, it looks like an interesting target for hobbyist and student embedded developers. It’s a cheap little board at around $150 US (a little more once you add the needed cables and a power supply to use it properly). The community there is working on getting the Angstrom embedded Linux distro running on the board and there are some cool videos of it working. Don’t doubt it, this is being driven by Texas Instruments, who makes the chips for this board, so it’s not purely a community driven project, but it looks like an independent community has formed and is running with it.

I think this would be a good choice to target an Eclipse for Embedded distro. I think a case could be made for qemu as well and the various CPUs and boards it emulates. And I assume you’d target Linux for these platforms. But then you open up the questions, which distro do you support, or do you make your own? And what about the other free or quasi-free RTOSes that have Eclipse support. At a minimum you need a cross compile and debug tool chain to integrate Eclipse with but what else would you need?

I get the feeling that this could turn into a pretty big project on it’s own. Which, of course means it won’t happen without a community behind it and maybe vendors to sponsor it. I’m interested in hearing your opinions on what this all should mean and what you would like to see in an open source Eclipse for Embedded IDE.

MinGW frustrations

Um, yeah, Wascana 1.0 keeps slipping. Work has been very busy leaving little time for me to work on it, but that should be clearing up in the next few weeks (I hope!). But as I did my testing for the release candidate of CDT 5.0.2, as I expected, I ran headlong into the gdb 6.8 issue that everyone seems to run into. I don’t know how many people I see on my Feedjit log searching for: “gdb eclipse No source available for “ntdll!LdrAccessResource()”. And I hope those people now find this blog entry instead.

The issue is that before gdb 6.8, there was no way to issue pending breakpoints using the MI protocol we use to talk to gdb. I think it was introduced in 6.7 from the CLI, but that doesn’t help us. To support breakpoints in shared libraries, we need to keep retrying to set those breakpoints on every shared library load event. That worked for many years. But now, the break on shared library event in the MinGW gdb 6.8 really messes up the CDT. And it’s mainly because it doesn’t work in gdb any more.

So the solution is to add support for pending breakpoints, at least into the MinGW debugger target. But, alas, I think that’s going to be a lot of work. And given I’m having trouble finding time to even get the p2 support for Wascana done, let alone dive into debug which I don’t really have expertise on.

At any rate, the experience is so bad, I’m starting to think of holding off Wascana 1.0 until Galileo in June. I can make the p2 repo available so people can download the same thing I’m testing with. But until this debug issue is resolved, it’s not an environment I’m happy to send out to the world.

That and there was an interesting conversation on the mingw users mailing list recently about the state of gcc 4.x for MinGW. I’ve lost faith that it’s ready for prime time as well.

It’s enough to make me wish we had a Windows debugger available and to complete our Visual C++ support (wink, wink, nudge, nudge to people who know who they are ;). For now, bear with me.