Howto create, build and run a simple KDevelop4 Project

As recently the number of users of KDevelop4 has grown and apparently there are quite some “newbies” among them (which is good, new users always mean we easily see flaws in our GUI) I’ve decided to do a small howto on creating, building and running a simple CMake based KDevelop4 project.

First of all: I’m using a Qt4 CMake project using just QtCore, which is the closest you get currently to a simple C++ “hello world” project. We currently don’t have good support for QMake and no project templates for plain Makefiles.

Now lets start the IDE. You get something like this:

You can create new projects via the Project -> New Project menu entry. Note: for this to work you need KDevelop to load all its plugins, as the menu entry and the underlying functionality is provided by a plugin. If you can’t see it, see my What to do when I don’t have New Project post. You should now see this dialog:

The image shows quite a couple of items in the tree, if you install only kdevplatform and kdevelop you’ll only have the C++ part and therein only the Qt subelements. The other entries are provided by kapptemplate, a program found in the kdesdk module. As I said before I’ll be taking the Qt4 CMake Core application, its under C++->Qt (cmake). After that I supply a project name and leave the default destination directory. This now looks like this:

I’ll skip the version-control page and just hit the Finish button. KDevelop now creates and loads the new project. I can now open the “Projects” toolview on the left and see the project. As this is a cmake project (and we suck and haven’t made this easier yet) you need to tell KDevelop a directory where you want to build the project. To do that open the projects configuration by right-clicking onto the entry in the “Projects” toolview and selecting the “Configure Project” context menu entry. You should now see the configuration dialog (I’ve selected the CMake page already):

With the little “+” button you can add a new builddirectory. This should either be a directory where you’ve previously run cmake for this project (which we haven’t done yet) or a non-existing or empty directory. I’ll be using a “build” subdirectory inside the project directory. Now hit the “Run” button and cmake should be run and its output should be printed in the list. The dialog now looks like this:

After clicking “Ok” KDevelop will read and parse the CMakeCache.txt file and show its contents. You can edit it here if you want to.

Now there are two ways of building the project, you can either again right-click the project entry in the tree and select the Install entry from the menu. Or you can use the buildset in the bottom of the Projects toolview. This allows you to build multiple projects (or files/targets/subdirectories) at once, you can simply add the selected entries from the tree by using the “+” toolbutton in the buildset widget. After that you can use one of the three toolbuttons to the left of the “+” button to build, install or clean. The entries in the Project menu to build, install and so on also use the buildset, so they only work when the buildset is not empty. KDevelop will show the output of running make in the bottom toolview. This is how KDevelop now looks after building the project (this project doesn’t support installation):

Now the last part: Running the created executable. Unfortunately this part is still changing a lot, so I’m not sure its working right now, but at least we can do the setup part. Again open the project configuration dialog by right-clicking onto the project entry in the treeview and selecting “Configure Project” from the menu. In the dialog open the “Run Settings” entry, in the run page click on the “+” button and give a name to the run configuration.

Select the “Executable” radiobutton and put the path to the executable (including the executable) into the lineedit. As my project resides in $HOME/testproject and the build directory is a subdirectory of that, the path here is $HOME/testproject/build/src/testproject. I’ve also set a working directory just to be sure this works (hopefully). The configuration can be seen here:

Now you should be able to select this run target under Run->Run Current Target, however it seems this part is currently not working. Lets assume it does, the last step is selecting the entry Run->Execute Program, which would print “Hello World!” into the bottom toolview.

I hope this helps those people trying to use KDevelop4 for the first time, if anybody has question: Just ask us on the mailinglist kdevelop@kdevelop.org (registration under http://www.kdevelop.org) or join us on freenode in #kdevelop.

Advertisements

Like this:

LikeLoading...

Related

14 Comments

Hello Andreas,

How can I stop those WordPress Snapshots?
If I tries to get rid of them my whole Kontact application crashed by just clicking on some buttons on these popups.
I like the story but those popups should not be there.

Nice, but I have some suggestions which might please the QtCreator fans 😉 To polish the GUI please consider to split the “General” page in “Create new project” into two pages. The cmake-output frame should be better a separate window. Now having two Cancel buttons is very irritating. And about the Configure dialog: Every section has the same icon. That looks ugly. I think it is hard to create individual icons for every task so better remove icons and only use them where they help to find an action quickly.

@Chris:
– why should the general page be splitted?
– the cmake dialog should just have a stop instead of cancel button. I don’t like this to be a separate windows, dialog popping up from dialogs are bad 😉
– I agree, however icons increase the click area. The future of that particular dialog isn’t decided anyway and we need icons from the artists too (so we may just add those to the request).

I really think this stuff should be on userbase- not on blogs. Only people reading the blog today or people who happen to google the right terms will read it.

Userbase is supposed to be the first stop to find this kind of content. I’d suggest writing the content on userbase (where it can be maintained and translated) and then linking or reproducing it on the blog.

Hmm, I think you missed my point about you putting it on techbase in the first place instead of your blog.

I’m not going to copy it over. I see a lot of content flow through planetkde that would be more suited to userbase. Maybe you think it is the responsibility of the community to copy content from your blog into userbase. I think it’s the responsibility of the person creating the content. That’s you in this case, but there are many others.

@steve: I suspected you meant it that way. Yes, ideally this blog post would also be on userbase. However there are (for me personally) a few problems with also putting it there or even in a forum:

a) I don’t have an account there and I already have too many of them
b) I’m not going to maintain the content, so it will get out of date, unless someone else takes care. That somebody either needs to follow a blog/planetkde or use the application in question, which means he could’ve put the content into userbase as well
c) If I put stuff into a wiki I like it to look good, eventually have named sections etc. This takes time, too much time during the night that I simply dumped this into the blog.

Looking at the current KDevelop page I’d have to do quite a bit of editing to get a proper structure, which is simply not going to happen right now.

So yes, its not good this is only available in the blog, but unfortunately I don’t see a way to make the content easily (for me, because I’m selfish) available on other sites.

@steve: It would have been great if you could have shot me an email to poke me about that rather than me noticing that someone linked to my site from here 🙂

Something that you might want to consider, as apaku mentioned, is that wikis are a lot harder to maintain and write if you aren’t used to them and don’t want to add another thing to your list of “things to do”. We developers could perhaps do a better job of clarifying our content licensing so people like yourself could do the blog -> wiki conversion for us.

@steve: Sorry, I missed where you say you won’t copy it over. To be honest, I think that’s a wee bit unreasonable for you to be telling us what we should and shouldn’t do. Any contribution to KDE for me (can’t speak for apaku) is in my spare time, on top of a busy job and a very busy life.

As I highlighted above, we have our reasons for posting on the planet and not on userbase and from the number of hits my KDE HOWTOs get on my blog and the high Google rank I’m not overly convinced that userbase would make it easier to find until userbase is actually heavily used.

Really, until I get paid to work on KDE or actually accept a position like e.g. a maintainer I have no “responsibility” to do anything, even bug or security fixes. My KDE work is a hobby and I try to consider the users of my code and fix any bugs they report but ultimately.

I’m grateful for your concern for the KDE community but in future perhaps consider doing some of the leg work yourself (e.g. offering to transfer articles) and remember that you’re lucky that so many developers work for free in their spare time to give you software.

Sorry for my post yesterday. It was unreasonable, out of place for this blog and a bit embarrassing. I didn’t intend to demotivate or be harmful. Either way this wasn’t the right place to vent about it.

I added links to both blog posts on the tutorials page on userbase. It’s not ideal, but I can probably keep it up to date for a while with content I see flying past.

Thanks apaku and mike for responding well and calmly to this and sorry again.