Fog Creek Software
Discussion Board




software dev. on Linux

I am starting a new job with development on Linux,i have worked in Unix before, but not on Linux.I am wandering if people using Linux use IDE's for file browsing,debugging  and development etc... or so people just go with
Emacs/Pico, GDB?
I have done most dev. with VC++ ,so I am wandering how much of a change there will be?

Andrew
Saturday, April 19, 2003

There are a number of good IDE's for Linux. Kdevelop is the free (gratis/libre) C/C++ IDE created by/for the KDE desktop project and is well worth a look. If you're used to Delphi, then there is a Linux version called Kylix. Eclipse is supposed to be really good, but I've never used it so I can't speak from personal experience. There are a whole lot more to be found at: http://linuxmafia.com/~rick/linux-info/applications-ides.html

David Roper
Sunday, April 20, 2003

I think you might be better off starting with the basics (Makefiles, gcc, and gdb). The various Linux IDEs are all based on these tools.

Kdevelop is pretty close to Microsoft's IDEs. Personally I don't use it because I find it too complex, but you might like it.

It sort of depends what kind of code you are writing: for low-level stuff (kernel or libraries), I'd definitely stick with raw Makefiles, gcc, and Emacs (or vi). For GNOME or KDE applications you might gain from an IDE.

Dan Maas
Sunday, April 20, 2003

I'm only a University student, and thus young, so please take this with a grain of salt. Having done almost all of my development thus far in either Linux or Free BSD, I've found that a good deal of the true IDE's on Linux feel rather half-baked. Out of the big players:

A) Eclipse : The JDT which supports java development is *awesome*. Great CVS integration, refactoring tools, code completion, and it looks great thanks when one uses GTK2 and the Bluecurve theme from redhat. A big problem with Eclipse is that the development toolkits for C or C derivatives are sorely lacking. Code completion is non-existent, there are no refactoring tools, and you have to write your makefiles yourself. Debugger integration was pretty shoddy last time I checked as well.

B) KDevelop : Nice, but I've always had a bit of a bone to pick with the GUI. First of all, I've never liked the 'feel' of the QT widget set (just a personal thing, your milage may vary) and the overall organization is rather poor. While functionality is there KDevelop feels very much like a poor man's Visual Studio.

C) Kylix : Sorry, I've never used Delphi, so I can't really comment on this one.

D) Emacs / Vi etc. I can't comment too much on vi, but if you're an emacs user, (or even if you're not though the learning curve is steep) I can't recommend emacs enough for developement on linux. The recent versions support GTK2, which means that you can have a clean-looking emacs which interoperates properly with Gnome. Emacs does lack the niceness / button based ui of most IDE's but once you learn your keystrokes, you can really zoom around.

While the standard for compilation on Linux seems to be autoconf / automake or just plain makefiles, I've been using
apache ant (with the cpptasks addon from the ant-contrib package available from http://www.sourceforge.net) to do 'one-step' compiles of a project I'm working on and everything works like a charm and I don't have to deal with the hell that is make. Furthermore, ant has great support for continuous compilation via cruisecontrol, all of which is available free of charge.

For a nice visual debuger I recommend ddd. You can view all the data structures in memory graphically and can be a great aid in debugging pointer / reference problems. DDD uses the motif toolkit, so It's pretty f*cking ugly, but it's functional.

Sorry in advance for any spelling / grammar mistakes, I am just a student :P

Hope this helps!

Andrew Murray
Monday, April 21, 2003

Don't forget about valgrind to find hairy errors.

S. Gwizdak
Monday, April 21, 2003

http://www.anjuta.org/

Anjuta is an IDE that us suitable for developing GNOME or command-line applications.

I use it regularly and reccomend it highly.

Tom Foottit
Monday, April 21, 2003

I can't testify as to the quality of the different IDEs mentioned here; never been a big user of IDEs.

For debugging, gdb is pretty good. DDD, a frontend to it, is better (being not a command line app).

Editing: go with whatever you like :) emacs,vim,etc. are great programs, if you know how to use them.

Building: autoconf/automake are good utilities for building C/C++ programs. They are their own form of Makefile hell, but once you learn it, it isn't too bad to get used to.

Most things are pretty easy to get autoconf/automake to use, especially if you're mucking w/ shared libraries.

If you're doing C/C++ development, look into ccache and distcc to help you compile things faster.

If you're going java, I'll second the Ant nomination: it works great. Note that since Ant itself is a java app, its compile times are horrendous: I'd suggest make and Jikes, with Ant for only when you really need the power. This setup gets me about a 2 second full build for 140+ class files (not huge, but still...).

Mike Swieton
Monday, April 21, 2003

Mike, I'm curious (truly).

How come you like autoconf?  Do you use libtool also (seem inseparable)?

I hate autoconf and libtool - I like gnu make, plain and simple - nothing standing between me and dependencies...

I find libtool to be an abomination, yet really intelligent people seem to like it.  How come?

Nat Ersoz
Monday, April 21, 2003

Nat:

My take on a whole lot of things is that when you use it for exactly what it was meant for, it works well. Often bastardizing those utilities for something different is hard/impossible, but...

This is where I stick autoconf/automake. Some things they make harder, but many things they make easier.

I have a tiny (sub-15kloc) program that has a few optional features (because why shouldn't they be optional?) and links against different libraries depending on linux distro (termcap stuff is sometimes in odd places, dammit!).

It lets me do these things without worrying about having to do all the detection stuff myself.

I have it do libtool also, but that's because I don't care _how_ the shared libs I have are created, only that they _are created_. I don't touch it in my code ever.

I also like how automake automatically generates the code to create distributions, build documentation, and do installs. Very handy, and it means I don't have to deal with it.

The tools work well for me, and it's not much work for me to setup, since I did it once :)

Mike Swieton
Monday, April 21, 2003

autoconf, automake and libtool are seriously gross and hairy, but they're also invaluable if you need to compile on a bunch of ugly, broken Unices with randomly missing libraries, incompatible APIs, and defective command-line tools.

autoconf generates an extremely portable shell script which tests many features of a Unix system, and selects the right compilation options for you.  To use autoconf, you need to understand Korn shell programming and read the manual carefully.

automake generates GNU-style makefiles automatically.  This is great if you're creating a new open source project from scratch, and pretty horrible if you already have a hundred makefiles and want to convert.  To use automake, you need to understand regular Makefiles and read the manual carefully.

libtool understands how to create shared libraries on many different platforms.  This is great is you're releasing a shared library and want it to run everywhere.  To use libtool, you'll need to understand linking and read the manual carefully (yes, there's a trend here--the manual is your friend).

You can use any combination of these tools.  autoconf is the most essential, and automake will worry about libtool for you if you ask it.  These three tools are a pretty hairy system to master, but if you're trying to write truly portable Unix software, they beats the alternatives hands down.

Eric Kidd
Monday, April 21, 2003

Thanks for the responses.  What I find frustrating with autoconf in particular is that we have to cross compile


My "problem" with autoconf, is that in general we're cross-compiling targets.  That is the libs & programs are not intended to be run on the machine that is compiling it.

So the tool chain, and link libraries are not where autoconf "thinks" they are.  I wind up having to unwind the configure logic and figure out how to force autoconf into using a different set of include/library search rules.

As I recall (it has been some time, thankfully), that several PREFIX rules can be predefined at ./configure time to force the issue.  However, these don't always seem to work(?) or the syntax is not always consistent.

I often (usually) just take the Makefile that is generated and hacking for to my liking.  The problem with this approach is integrating new code which might come packaged with autoconf.  Anyhoo.

Nat Ersoz
Monday, April 21, 2003

Special case, but I haven't ever liked GDB/DDD. Combination of not being able to do what I want it to do and not working right when I DO know what I want it to do. Plus, it lacks a bunch of features that I use a lot (cross reference, scripted breakpoints, etc).

On the other hand, I work on an IDE which we use ourselves, so I'm both (a) biased and (b) not a gdb guru.

Steven C.
Monday, April 21, 2003

steve:

what debugger do you use? I use GDB because it comes close enough to the few things I need most of the time, and because I can use it via a remote command line (no X required). I've not looked hardly at all, but I've also seen little in the way of other debuggers for *nix.

Mike Swieton
Monday, April 21, 2003

I know there are a fair number of (reportedly) good graphical debuggers for linux, as there was a thread about them just a week or so ago, so you might want to look for that thread for a more complete listing.

The graphical debugger I use is MULTI 2000 (developed by Green Hills Software). It is primarily an IDE for embedded developers, although we also sell linux, solaris, and win32 native tools (and we use them internally to compile and develop our own products).

Steven C.
Monday, April 21, 2003

You can try Magic C++ instead.A handy visual remote Unix and Linux C/C++ IDE under windows just like VC++. It provides a "hello world" template, you can generate a "hello world" project by project wizard, you'll get something fairly easy to use. You can edit the source codes and debug it handily with this VC++ like IDE :-)

Magic C++ download site:
http://www.magicunix.com

A "hello world" step by step tutorial( html format with illustrates )
http://www.magicunix.com/download/step_by_step.zip

8route
Friday, June 11, 2004

*  Recent Topics

*  Fog Creek Home