1 files changed, 128 insertions, 0 deletions
diff --git a/doc/kdevelop/adv-build-management.docbook b/doc/kdevelop/adv-build-management.docbook
new file mode 100644
index 00000000..e589a007
--- /dev/null
+++ b/doc/kdevelop/adv-build-management.docbook
@@ -0,0 +1,128 @@
+<chapter id="adv-build-management">
+<title>Advanced Build Management</title>
+<indexterm zone="adv-build-management"><primary>&automake;</primary></indexterm>
+
+<sect1 id="buildconfigurations">
+<title>Multiple Build Configurations</title>
+<indexterm zone="buildconfigurations"><primary>build configurations</primary><secondary>multiple</secondary></indexterm>
+
+<para>
+(... to be written ...)
+</para>
+
+</sect1> <!-- buildconfigurations -->
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+<sect1 id="crosscompiling">
+<title>Cross-Compiling</title>
+<indexterm zone="crosscompiling"><primary>cross compiling</primary></indexterm>
+<indexterm zone="crosscompiling"><primary>compiling</primary><secondary>cross</secondary></indexterm>
+<indexterm zone="crosscompiling"><primary><option>--host</option></primary></indexterm>
+
+<para>
+When you have suitable cross compilers available, you can cross compile your
+programs for processors and operating systems different from the system where
+&kdevelop; and the compiler is running. The &GNU; compiler collection &gcc; can
+be configured and compiled as a cross compiler if you compile it yourself.
+Consult the <ulink url="info://gcc/Cross-Compiler">GCC info pages</ulink> for
+more information. Some &Linux; distributions also provide binary packages.
+</para>
+
+<para>
+An <application>automake</application> based package can easily be
+cross-compiled by specifying the <option>--host</option> option to the
+configure script and setting the <envar>CC</envar> and <envar>CXX</envar>
+environment variables to the respective cross compiler binaries. Often you
+want to switch between a the cross-compiled version of your application and
+one compiled for your development system. For this, it is advantageous to
+use &kdevelop; capability of creating multiple build configurations, as
+explained in <xref linkend="buildconfigurations"/>. Once you have created a
+new build configuration for cross-compiling in the
+<menuchoice><guimenu>Project</guimenu><guimenuitem>Project
+Options...</guimenuitem></menuchoice> dialog, add the option
+</para>
+
+<screen><option>--host=</option><replaceable>platform</replaceable></screen>
+
+<para>
+to the configure options. The <replaceable>platform</replaceable> name
+is a tuple of the form
+</para>
+
+<programlisting>cpu-vendor-os</programlisting>
+<para>or</para>
+<programlisting>cpu-vendor-kernel-os</programlisting>
+
+<para>
+For many combinations, you can use a short form, for instance
+<wordasword>i386-linux</wordasword> or <wordasword>arm-elf</wordasword>.
+</para>
+
+</sect1> <!-- crosscompiling -->
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+<sect1 id="qtembedded">
+<title>Qt/Embedded</title>
+<indexterm zone="qtembedded"><primary>embedded</primary><secondary>Qt</secondary></indexterm>
+<indexterm zone="qtembedded"><primary>Qt/Embedded</primary></indexterm>
+<indexterm zone="qtembedded"><primary>Qtopia</primary></indexterm>
+<indexterm zone="qtembedded"><primary>framebuffer</primary></indexterm>
+
+<para>
+&qte; is a version of the &Qt; library that does not use the X window
+system, but draws directly to the framebuffer on &Linux; systems. It is
+therefore interesting for embedded systems which have tight restrictions
+on the memory usage of the whole system. Its &API; is fully compatible with
+the one of the X11 version.
+</para>
+
+<para>
+Developing an application for &qte; with &kdevelop; is not very different
+from developing a program for the X11 version of &Qt;. In fact, you can use the
+same codebase for both versions. If you use the autoproject project
+management, you switch to the embedded version by passing the argument
+<option>--enable-embedded</option> to the configure script. You can set
+this in the <menuchoice><guimenu>Project</guimenu>
+<guimenuitem>Project Options...</guimenuitem></menuchoice> dialog under
+<guilabel>Configure Options</guilabel>. With the option
+<option>--with-qt-dir=DIR</option> you set the directory in which &qte;
+is installed.
+</para>
+
+<para>
+After configuring and compiling your application with these options, it will
+link with the <filename>libqpe.so</filename> library. This version of your
+application will not normally run when you use X11. In order to test it,
+run it under the control of the program <application>qvfb</application>
+(&Qt; Virtual Frame Buffer). This is done by starting
+<application>qvfb</application> and then starting your application with
+</para>
+
+<screen><command>app <option>-qws</option> <option>-display QVFb:0</option></command></screen>
+
+<para>
+Naturally, when you have a working version of your application, you
+will want to use it on the target processor. For this, it will probably
+be convenient to create multiple build configurations, as explained above,
+so that you can quickly switch between the version running on your development
+system and the version running on the target system.
+</para>
+
+<para>
+Applications for &qte; normally run as single applications on the
+device they are designed for. Trolltech also supports Qtopia, which is a
+collection of applications for PIM, web browsing and various other areas that
+work together in a consistent manner. It is the standard environment for
+instance on the Sharp Zaurus. You can write applications that integrate into
+this environment by using the Qtopia SDK. This implies making your application
+class a subclass of <classname>QPEApplication</classname> and linking to the
+library <filename>libqpe.so</filename>. If you develop your application with
+the autoproject project management, you have to add
+<option>--enable-qtopia</option> to the configure options.
+</para>
+
+</sect1> <!-- qtembedded -->
+
+</chapter> <!-- adv-build-management -->