tdevelop/doc/kdevelop/adv-build-management.docbook

<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 -->