Sessions and projects: The basics of KDevelopTable of Contents
In this section, we will go over some of the terminology of how KDevelop sees the world and how it structures work. In particular, we introduce the concept of sessions and projects and explain how you can set up the projects you want to work on in KDevelop.
KDevelop has the concept of sessions and projects. A session contains all projects that have something to do with each other. For the examples that follow, assume you are the developer of both a library and an application that uses it. You can think of the core KDE libraries as the former and KDevelop as the latter. Another example: Let's say you are a Linux® kernel hacker but you are also working on a device driver for Linux® that hasn't been merged into the kernel tree yet.
So taking the latter as an example, you would have a session in KDevelop that has two projects: the Linux® kernel and the device driver. You will want to group them into a single session (rather than having two sessions with a single project each) because it will be useful to be able to see the kernel functions and data structures in KDevelop whenever you write source code for the driver — for example so that you can get kernel function and variable names auto-expanded, or so that you can see kernel function documentation while hacking on the device driver.
Now imagine you also happen to be a KDE developer. Then you would have a second session that contains KDE as a project. You could in principle have just one session for all of this, but there is no real reason for this: in your KDE work, you don't need to access kernel or device driver functions; and you don't want KDE class names autoexpanded while working on the Linux® kernel. Finally, building some of the KDE libraries is independent of re-compiling the Linux® kernel (whereas whenever you compile the device driver it would also be good to re-compile the Linux® kernel if some of the kernel header files have changed).
Finally, another use for sessions is if you work both on the current development version of a project, as well as on a branch: in that case, you don't want KDevelop to confuse classes that belong to mainline and the branch, so you'd have two sessions, with the same set of projects but from different directories (corresponding to different development branches).