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