Best IDE for OSDev / Cross Compiling

[Lionel]

Hi, I have been looking around for a good IDE that works well with a cross-compiler.
So far, haven't found it.
Any Recommendations?
P.S (DO NOT Criticize another suggestion unless it is a valid point, I don't want to start a flame-war)

[CrypticalCode0]

I personally still like the DEV-C++ IDE but that hasn't seen a update in nearly 6 years.
http://www.bloodshed.net/

[Rusky]

Code::Blocks is a nicer (and more up to date) compiler that is easy to configure for cross compilation, but it's not the greatest IDE on the planet.

Depending on your preferences, Eclipse could be better than Code::Blocks, but it's a lot more heavy-weight.

Personally, I prefer vim with a Makefile and terminal.

[bluemoon]

I use xcode with Makefile, so, I suppose any IDE that support make system is good.

[AJ]

Hi,

As Rusky suggested, I find Eclipse quite good (and very configurable), but you'll want a reasonably decent PC to run it on. On my old machine, it was a nightmare and seemed to occasionally lock up for 5-10 seconds (I think when loading code completion caches). On my current machine (6 months old), it's very useable.

@Rusky: I've only tried the old version of Code::Blocks, which the dev team seemed to be rewriting for ages. Thanks for reminding me to try the latest incarnation!

Cheers,
Adam

[Jvac]

I agree with Rusky and AJ Code::Blocks is a good choice. Also try the NetBeans IDE see their configuration page here.

[OSwhatever]

As OS development is not really a standard environment, how much can you really integrate into your editor of choice? I think most of us use some kind of custom makefile build, then the project options doesn't really apply. Also the good old debugging with source directly in the editor doesn't work as standard. I presume that you can configure Eclipse to do pretty much anything but I can't really get my head around it.

For me IDE is basically just an editor, then I use the command line for building and debugging. What would be more interesting to hear from you is if you have made customizations for your IDE in order to make it work with your OS and build system.

[JackScott]

I use Netbeans. It's not perfect (it's almost as big of a memory hog as Firefox!) but it does the job. It allows me to use my custom makefile still integrated with the IDE, is happy to do autocomplete with my custom library and include locations and is happy to use a cross-compiler. It also integrates nicely with pretty much every revision control system out there (though there are a few bugs using git+ssh or svn+ssh on Windows, due to Windows not having a native SSH client.

I agree with others' sentiments that any IDE that supports a Makefile is a good IDE.

[Cognition]

Currently I use Code::Blocks, in the past I have used CodeLite as well. Mainly because these IDEs do enough of what I want without too much hand holding and the ability to use makefiles. It hasn't had a solid release version in a while, but it's still developed pretty actively if you grab a nightly build or pull the trunk from SVN.

[trinopoty]

I use Microsoft Visual C++ 2008 Express Edition IDE to do all unmanaged development, including os dev.

[rdos]

Open Watcom's IDE. That is all that I need. That way I don't need to do any makefiles for neither device-drivers nor for applications / libraries, as OWs IDE can handle all of these targets. As an extra benefit, it can also build tools that run under Windows (for instance, my image creator, cfg2bin).

[Love4Boobies]

I used to use Dev-C++ and Code::Blocks but nothing has made me happier than Vim which, amongst other things, I was easily able to integrate with both my build system and a debugger. I realize that Vim is technically a power editor but it can easily be turned into an IDE---however, IDEs do not offer the power and flexibility of power editors. It's also much easier on the wrist, as I can get at any position in the source code in only a few key presses without even moving my hand all the way to the mouse/trackpad or arrow keys. It feels like an extension of my hand.

[Solar]

Love4Boobies / VIM +1.

Once you start using VIM the way it was designed for, instead of trying to use it as your regular "modern" editor with some strange key bindings, you won't look back. Last year I finally got around to figuring out how VIM macros and key mappings work, and boy did it increase my working speed. I even found a VIM plugin for Visual Studio.

It's also truly cross-platform, fast, easy on memory (e.g. when working on my 128-MByte pocket computer), and works perfectly well across even slow SSH connections.

[Kevin]

So what are the configuration changes that both of you made?

I just checked my config and there isn't much special stuff in it. The only big thing is cscope integration (which I consider essential), and then there are smaller useful things like highlighting trailing whitespace or anything > 80 characters in a source file, enabling FPC extensions for Pascal syntax highlighting etc. I tried things like omnicppcomplete because everyone keeps saying that you absolutely need some context-sensitive autocompletion, but to be honest I found it to be more annoying than helpful. So I'm back to Ctrl-P for now.

[Solar]

Not much, really. I have my ~/.vimrc online, including comments, and have so far not included any "fixed" mappings or macros in it.

But I use macros daily. Most of them are solving repetitive, project specific problems, like "the usual" source reformatting for stuff written by a specific co-worker, "the usual" stuff I do to certain LaTeX table source after hacking in the raw data, things like that. Others are one-shot, I-won't-need-this-again. Neither does warrant including them in ~/.vimrc, since VIM saves them on exit anyway - I'll still have them tomorrow.

But knowing about how they work did wonders for me. Before that, I needed either UltraEdit (which has a comparably powerful macro function but isn't available on all machines I work on), or had to write some Perl ad-hocery for the purpose. Now, I don't have to leave the editor, which is a nice big win for me.