Git commit 132d05cf5a902d9d50d415de17cca12e720a29d5 by Burkhard L?ck. Committed on 24/02/2013 at 18:45. Pushed by lueck into branch 'master'.
remove consecutive duplicate word >working< M +1 -1 doc/kdevelop/index.docbook http://commits.kde.org/kdevelop/132d05cf5a902d9d50d415de17cca12e720a29d5 diff --git a/doc/kdevelop/index.docbook b/doc/kdevelop/index.docbook index d9f075b..38bc7b8 100644 --- a/doc/kdevelop/index.docbook +++ b/doc/kdevelop/index.docbook @@ -72,7 +72,7 @@ double bar () <sect1 id="terminology"><title>Terminology</title> <para>&kdevelop; has the concept of <emphasis>sessions</emphasis> and <emphasis>projects</emphasis>. 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.</para> <para>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.</para> -<para>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 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).</para> +<para>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).</para> <para>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).</para> </sect1> <sect1 id="setting-up-a-session-and-importing-an-existing-project"><title>Setting up a session and importing an existing project</title>
