In my opinion, the above three IDEs all have their strengths and weaknesses depending on what kind of project you are working on. Here are some of my observations.

KDevelop is probably the most comprehensive IDE of the three. This should not come as a surprise as it has been around for more than 10 years and it bas been the de facto development environment for most of the KDE development work. It is very feature rich and you can use it to develop many different types of applications natively out of box (e.g. KDE, GTK+, Qt, wxWidgets, etc). If you are developing GNU style applications, you will benefit from the Automake project type if provides. Besides the vast functionalities KDevelop provides, it is also very fast, efficient and stable.

Nonetheless, KDevelop is not the most intuitive IDE and does not suit small projects (e.g. prof of concept code) well as the initial project setup can be time consuming.

Code::Blocks is a very capable IDE for C++ development as well. It offers many project templates even though it does not offer native KDE project types. This should not be a problem to most people however. Among the features I like the most is that it does not require explicit make file configuration and the build dependencies are inferred by default. This makes it very attractive for rapid prototyping. Debugging under Code::Blocks is also a pleasant experience. It also integrates (at least in the later SVN versions) Valgrind‘s MemCheck and Cachegrind, which are very useful for detecting memory leaks and tweaking algorithms for the maximum performance.

The latest stable version of Code::Blocks is 8.02, it is a little dated as a lot of functionalities have been added in the later SVN builds. If you do not require the most stability (I have run into some issues recently), using SVN build should not be a problem. The editor (e.g. syntax highlighting, collapsible regions) is a little bit buggy though and the contextual help does not always work to the level of detail I desired.

NetBeans C++ IDE is probably the most beautiful one among the three. It offers the most detailed syntax highlighting, and can be configured to display class hierarchy and library function information. The refactor tool works pretty well and is certainly a boon to large scale development. Its contextual help is also of top-notch.

All of these come at a cost of course. NetBeans C++ IDE is the most resource intensive among the three. It can easily use 500 MB memory when doing development and can be sluggish at times. It also comes with a very limited project template (e.g. no out-of-box project templates for Qt, wxWidgets). Certain settings are hard to get at as well. Nevertheless, if I am primarily writing back-end code, NetBeans C++ IDE could easily earn my top choice.

Some people like Anjuta and compare it favorably to Code::Blocks. But I haven’t got a chance to use it yet.

So naturally, I wanted to revert back to my previous working version (SVN 5489). There are some instructions on lgp203.free.fr that in theory should work to install any revisions of Code::Blocks from SVN. But the script provided there did not work for me as it was complaining about not able to find certain packages. So I decided to do it manually, and here are the steps I took to get SVN 5489 installed.

First, you will need to remove the installed version of Code::Blocks.

sudo apt-get remove codeblocks
sudo apt-get remove codeblocks-common

Then you will need to install the Debian packages one by one from lgp203.free.fr. using

wget http://lgp203.free.fr/pool/codeblocks/wxsmith-headers_8.02svn5489_all.deb
wget http://lgp203.free.fr/pool/codeblocks/libwxsmithlib0_8.02svn5489_amd64.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks-headers_8.02svn5489_all.deb
wget http://lgp203.free.fr/pool/codeblocks/libcodeblocks0_8.02svn5489_amd64.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks_8.02svn5489_amd64.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks-common_8.02svn5489_all.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks-contrib_8.02svn5489_amd64.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks-contrib-common_8.02svn5489_all.deb

sudo dpkg -i wxsmith-headers_8.02svn5489_all.deb
sudo dpkg -i libwxsmithlib0_8.02svn5489_amd64.deb
sudo dpkg -i codeblocks-headers_8.02svn5489_all.deb
sudo dpkg -i libcodeblocks0_8.02svn5489_amd64.deb
sudo dpkg -i codeblocks_8.02svn5489_amd64.deb
sudo dpkg -i codeblocks-common_8.02svn5489_all.deb
sudo dpkg -i codeblocks-contrib_8.02svn5489_amd64.deb
sudo dpkg -i codeblocks-contrib-common_8.02svn5489_all.deb

You can find a full list of all the available Code::Blocks’ SVN versions here. Now, I am running version 5489 and everything is working again.

I personally like simplicity of Code::Blocks when writing small programs. Even though Code::Blocks does come with Qt support, you will have to tell it where Qt is installed before you can compile your code correctly. Like any other C++ environment, the two things you must provide are the include path and the linker path.

Ubuntu 8.04 comes with Qt3 installed, to install Qt4, please follow the instructions here. Here are the build options you need to add with the default Qt4 install:

As a bare minimum, you will need to set the libQtGui and libQtCore libraries paths. Note thatUbuntu 8.04 comes with Qt3 installed, when you specify the libraries you need to make sure you specify the ones with the correct version. In my example, the required Qt4 libraries are /usr/lib/libQtGui.so.4 and /usr/lib/libQtCore.so.4. You also need to specify where the include files can be found. For typical applications, /ur/incude/qt4 and /usr/include/qt4/QtGui are the paths you will need. If you want contextual help to be available, you will have to provide the search paths for the include files under "C/C++ parser options" tab in Project/targets options settings.

KDevelop is a powerful multi-language development IDE that comes as default package for the KDE environment (e.g. Kubuntu). For those who are using GNOME, it can be easily installed via apt-get install (Ubuntu).

The KDevelop IDE is one of the most feature-rich inegrated programming environments on Linux, but unfortunately it is not the easiest to get started due to its overwhelmingly large feature set. Here I will show you what I found the easiest way to set up a project that supports TBB, using the Automake project type.

The version of KDevelop I am using is 3.5.9. The commands might be slightly different in other versions, but the idea should be the same. To start a TBB application, use Automake project type (Projects -> New Projects, under C++ Automake Project, choose Empty Autotools Template.)

Don’t be surprised to see a few dozens of files being created, most of these files are used for program auto-configurations.

For all Automake projects, an active target is needed. So we will need to create an active target. By default, all the targets are configured within the right-hand-side split panels. The name of the active target will be compiled into the binary executable. In my example below, the target is named as tbbdev. In my example, I will use one of the stock program (sub_string_finder.cpp) that came with the TBB source code. It can be found in {TBB Source root}/examples/GettingStarted/sub_string_finder/

 In order for the target application to find the shared library at runtime, we need to setup an environment variable LD_LIBRARY_PATH. The setting can be found at Project -> Project Options.

In the example given above, the TBB library source was extracted within my user’s root folder under tbb (/home/kwong/tbb/tbb20_020oss_src/), and the library I used is for 64 bit operating systems. Depending on whether it is debug build or release build, choose library path accordingly.

Next we need to configure the build target. The include paths are configured at the root project level (which is the parent to all configured targets).

the added directory should take the following format: -l{TBB installation root}/include/.

Then we will configure the target library path (this takes place at the active target level):

2

Note the syntax, the first part (-L) specifies the library path, and the second part (-l) specifies the library name. The actual library is called libtbb_debug.so.

That’s all the settings you will need to compile and run the sample program. Before you start debugging though, make sure that the current target is set to be built in debug mode (For some reason, the default build config does not support debugging and thus you can not set breakpoints within the IDE):

Alternatively, you can also change the compiler flags (CXXFLAGS) to -O0 -g3 (in prorject options).

After the above steps, you should be able to compile, debug and run the sample TBB program from within KDevelop.

As I suggested earlier, Kdevelop might not be the easiest to configure and run since it is mainly geared towards the more complex KDE applications. If you are so used to Microsoft Visual Studio IDEs, you might find Code::Blocks much easier to use.

Start Code::Blocks, and choose File -> New -> Project and choose Console Application. Again, we will use the sub_string_finder.cpp sample code. The library path/include path properties can be set either at the Workspace level (one workspace can contain multiple projects and the settings are inherited unless overwritten) or project level. Assume that we are configuring at the workspace level. Click and highlight the workspace, and choose from menu Project -> Build Options and click on the Linker settings tab. Add the libraries to be linked here:

Note that only the first entry was necessary for this particular project. As you can see from above, you can configure multiple library dependencies here easily. Now click on the Search directories tab, and set up the include path:

Now you can build and debug the application in Code::Blocks.