On Sun, 4 Sep 2005, Michael Sternberg wrote:
We're looking for recomendations on *nix IDE.
oh, brother... you've opened the un-satisfiable can-of-worms...
Following virtues are seeked:
1. Multiplatform. We will develop on Linux and SunOS. Maybe AIX and HP in
the future.
you forgot one other platform.... ms windows ;)
2. Truly integrated. That is, good editor, source browser and visual
debugger in one bottle. Never mind that it will use external utilities
like ctags/make/CC/dbx/gcc/gdb/gprof underneath. Even better if it will be
able to use multiple external compilers or debuggers.
ah, here you're stepping on the first trap. "truly integrated" exists in
many flavors. you have to realize that 'integration' is different for
different people.
3. Good multithreading support is a MUST.
as someone states - this is in the debugger. since both solaris's dbx and
linux's gdb support multi-threaded debugging to some degree, and since
almost all visual debuggers (either inside an IDE or stand-alone) sit on
top of them - you'll get the level of multi-threading support that those
debuggers will provide you with. the only visual debugger for
linux/unix i'm aware of that does NOT run on top of an existing debugger,
is called 'ups', and seems to be only half-maintained (last release made
on 2003).
4. Reasonably light, does not demand very much resources.
"there's no such thing as magic". well, perhaps there is - emacs/xemacs -
relative to any other existing IDE (including visual C++) it is
lightweight ;)
5. Does not demand installing additional heavy packages (like KDE for
KDevelop)
i would ask - why? do you plan on making 20 IDE installations every day?
often, you'll only need to spend 1-2 days in preparing a 'prototype
development workstation', and then make a script to roll out a new
development work-station. i'd advise against using this as a "go/no-go"
criteria.
6. Not beta version or something - we're looking mature working package
7. Never mind open source or commercial
Do you know about something like this ?
no. because whatever you'll find, it'll never be "like visual studio".
however, if you are open minded, after all, you might want to check out
the following:
1. xemacs and similar things. this is "the one true IDE" for unix (no, i
don't use xemacs or emacs myself).
2. slickedit - it's commercial, portable to many platforms (including
windows), and will not force you to use some arcane project-file format
that'll lock you in, and lock you out of nightly builds. many people
swear by it (including the unix developers at my current work-place).
3. i've been following "code-forge" in the past - they are quite
expensive, though, and i don't know how good they are now.
one more think to consider regarding unix development - you don't realy
need an IDE for each platform you're going to support, since the
development (assuming user-space code - for kernel space there is NO IDE
on unix platforms) is mostly done on one platform (unless your
programmers have strong preferences to do their major development on a
given platform), and only a short porting session is done on the other
platforms. the rest is debugging - which requires a debugger, not a
full-fledged IDE.
eclipse, that people reminded here, is written in Java. as such, it
requires a lot of resources to run properly. resources = RAM. on the other
hand, since i assume you already have at least 0.5GB of RAM for your
existing development workstations, you might not consider this to be an
issue.
p.s. you will _realy_ want to make sure you're using Makefiles, and not
some proprietary project file format, in order to build your software, and
so you'll want to make sure that any IDE you choose does not lock you in -
it could get quite nasty if you need to port to some platforms that your
IDE-of-choice does not support.
p.p.s. i've seen some company (that i will not name here) that set up
visual studio to be their (almost full) IDE for development on linux -
except for running a debugger. they used 'ddd' for debugging. if you go
that path, you'll need to perform some scripting in visual studio, and
mind the translation of end-of-lines from windows format to unix format.
this can, of-course, be automated.
p.p.p.s. when you give up, i'll give you some good references for vi ;)
