Eclipse for C programming
A few weeks back I started trying out Eclipse after reading that Eclipse 3.3 with CDT 4.0 (C/C++ Development Tools) was released.
For anyone who want to try this out, don’t use gcj. I started out trying the gcj compiled version which turned out to be a lot slower (to the point where it was lagging when you typed). After switching to Suns JDK, speed of the UI was great.
I’ve semi-followed CDT for a while in the hope that it will be able to provide a nice IDE for C development. Not only an editor with GDB-integration (Emacs and Vim does that
) but also some of the nicer features you can find in modern IDEs. Like code awareness, indexing of symbols, type-ahead completion, refactoring capabilities etc.
With CDT 4.0 it is definitely becoming usable for programming C and comes with many nice features that can improve your productivity and reduce jumping around in the code just to look at definitions/implementations of certain functions.
For example when you hover a function call you get a tooltip with as much information possible (if Eclipse can access the implementation it will show it, otherwise the declaration).
A short screencast showing a session hacking Loudmouth 2 which is the project I’ve used for trying Eclipse out over the last few weeks.
test_func leaks the LMSession object.
Pah, if you’re using our JDK anyway, http://www.netbeans.org/products/cplusplus/features.html is what you really want
Well observed iain and thanks for taking the time to view the film.
For powerful indexing and old school programmers, you still have cscope (http://cscope.sourceforge.net/) and a nice interface, from our neighbors, kscope (http://kscope.sourceforge.net/).
If you are interested in future work that can be done for a maintainer of code, could be useful give a read to the paper “An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks ” (http://www.cs.cmu.edu/~ajko/papers/Ko2006SeekRelateCollect.pdf).
The authors used Eclipse as a case of study and they gave recommendations about future improvements.
Technically you weren’t using gcj, but were just using gij, the interpreter. That is, unless Ubuntu has SDK 3.3 and CDT 4.0 .debs already but I don’t think they do. Using just the interpreter is not feasible as you discovered :). gcj is the ahead-of-time compiler (gcc frontend) that creates the .sos that are used instead of just in vanilla bytecode interpreter.
I’m glad you found things useful. You should try out Jeff Johnston’s work on autotools integration: http://sourceware.org/eclipse/autotools
I think it should work against 4.0 clean but I don’t think he has an update site yet that you can use with the upstream download. I’ll get him to do that.
Andrew, ah thanks for the clarification. Very nice to see that there is work going on to improve the experience when working with autotools projects.
I’m hoping to spend some time to look into some GObject-integration of sorts. If nothing else a GObject-generator.
Sweet. Ben Konrath has always talked about GObject integration but we’ve barely kept our heads about water over the past few years. I *think* the upstream CDT guys want to take in the autotools work for their next release. Either way, it’s pretty nice stuff and it’s improving all the time:
http://overholt.ca/wp/?p=82
Jeff’s always looking for ways to test it. He’s pretty much got everything working for projects like gdb (he used to work on it) but things like GNOME or Gtk projects he doesn’t really know how to test them. If you could provide him with some guidance on how he can ensure things work, that would totally rock. He’s jjohnstn@redhat.com but he’s off until Monday so if he doesn’t reply it’s not ’cause he’s not interested
Eclipse is pretty good now. I’ve found I like PyDev for doing Python work.
By far the biggest issue I’ve found is that it’s really hard to just open random projects and work on them. Say I want to work on jhbuild all of a sudden; I have to go through the whole Create Project thing…ick.
Colin: I was discussing the whole project thing with Tom Tromey the other day. He was noting how it’s odd that emacs hasn’t grown the notion of projects yet. It really makes it handy for things like version control and bug tracking since you can just tack that onto the project metadata. Unfortunately, it makes it so that everything has to be in a project. I like to think of this enforcing things being in version control, but I can see how it’s a pain to hack on a random file. The JDT supports pasting a random .java file into the workspace and creating a project for it on the fly. See about half-way down here:
http://archive.eclipse.org/eclipse/downloads/drops/S-3.3M1-200608101230/eclipse-news-M1.html
I still strongly prefer SlickEdit. It’s not for free but it blows away anything I’ve seen/used before.
Regarding Andrew’s comment above, I just wanted to verify that the Autotools for CDT 4.0.0 is now available on the Sourceware Eclipse update site:
http://sourceware.org/eclipse/update
You can find details on how to install it from Eclipse at: http://sourceware.org/eclipse/autotools
I should note that there is a bug in the CDT code such that the resultant binaries of your Makefile do not appear in the Binaries folder. This minor annoyance is being worked on for 4.0.1. The binaries do exist, but the CDT doesn’t look in the folder you supply in your configure. You can manually configure the Run dialog to run these binaries, but if they were in the Binaries folder, all you would have to do is to right click and choose “Run as a C/C++ executable”.
Thanks a lot for the update Jeff, looking forward to try it out.