In the most cases you do not want to compile a complete GPE framework manually, there are build systems like Openembedded[6] or T2[7] which do this work for you. On many hardware platforms you can use binaries from one of the embedded Linux distributions like e.g. Familiar[8]. The Familiar binaries are expected to work fine on most ARM based platforms. There are only a very few bits in GPE which have platform-dependent switches, so there is usually no need to compile packages specific to a particular platform. Currently we work on switching the build system from our own Makefiles to Autotools the way to compile the components GPE consists of.

The basic needs for GPE development are a PC running Linux (or a similar UNIX-like operating system) and a X window system with compiler and some libraries installed. GPE applications are basically just GTK applications like many others. In this context GPE application development is quite uncomplicated. What do i need to install? C Compiler make intltool Autotools (autoconf/automake) GTK2 and its development packages. SQLite and its development packages. GOB2 - the GTK object builder. (for older library revisions) DBUS For the compiler you usually want to use GCC which is included in most modern operating system distributions. All versions >= 3.0 should work without trouble. The GTK libraries will pull in some other libraries they depend on (things like GDK, Pango, ATK, X11). To be sure all parts of GPE work properly it is recommended to use GTK 2.6.0 or higher. SQLite is a small in-process SQL database which is used by various GPE applications for data storage. Currently GPE uses the typless 2.x versions of SQLite. More and more GPE bits require GNU autotools to build. Some old versions of autotools are known to cause trouble. If you use autoconf >= 2.50 and and automake >= 1.9 you should be safe. Apart from the basic libraries necessary for almost all GPE applications some parts of GPE depend on other external tools and libraries. Most important are BlueZ (for gpe-bluetooth), OpenOBEX (gpe-beam, gpe-bluetooth), libmimedir (PIM applications), Cairo (gpe-appmgr, gpe-bootsplash, libgpewidget if activated), libmatchbox (gpe-what, gpe-mininet). One important thing to know is that not all parts of GPE use autoconf and automake. Therefore you currently need to know two different ways to pass build parameters to get the software built in the correct way. All bits using autotools are built in this way: ./configure --prefix=/someprefix --host=some-host make make install If the part you intend to compile ships with a Makefile instead of a configure script this meand that it isn't using autotools. To compile this you need to pass necessary parameters to make directly. For example: make PREFIX=someprefix CC=some-gcc make PREFIX=someprefix install Usually you just wnat to use the defaults if you wnat to compile for your PC you are on. In this case just omit any parameter, the build prefix defaults to /usr/local which should be correct in the most cases. If you are building from CVS you need to generate the configure script first by running autoconf, automake, intltool and friends in the correct order. Ususally applications ship an autogen.sh which does this for you.

In order to develop or evaluate GPE applications on a PC without crosscompiling it is very useful to have a local test setup. Instead of an emulator which is used for similar application frameworks you only need an X server for GPE. To get a PDA-like test environment you can use Xoo (formerly matchbox-nest) to emulate the look and feel of your device. If your distribution ships the packages to set up Some applications and libraries necessary for the GPE test environment are available in Ubuntu and Debian. What you should have installed is this: matchbox matchbox-desktop matchbox-panel Xephyr or Xnest Xoo or matchbox-nest matchbox All of this should be available in distributions based on Debian. Then start to build the very basic GPE bits you need to get everything up and running. Build and install gpe-confd, if you install gpe-confd on your local system remove /etc/X11/Xsession.d/70gpe-confd as it might break Gnome. Build and install libgpewidget, if you don't have Cairo you maybe want to --disable-cairo. Install gpe-conf unless you intend to use (and emulate) a device with a big (>640x480) screen. If you have everything in place you are ready for a test run to bring up the whole thing. First start Xoo or matchbox-nest. These default to provide a nested X server running on the local display :1. If you want to use a custom screen size or do not have these you can run Xnest like this: Xnest -ac -geometry 240x320 :1 Adjust the geometry parameters according to the display resolution of your need. In a terminal window set the correct DISPLAY environment fot the nested X server: export DISPLAY=:1 Then bring up your session and configuration server from this terminal: matchbox-session& gpe-confd& And finally start the gpe-conf look & feel tool to set up font sizes and toolbar display either from the desktop you just launched (Settings->Look & Feel) or from terminal (gpe-conf theme). You now have the basic environment to build and test GPE applications. To build the remaining GPE applications you the dependency list at http://handhelds.org:8080/gpe/wiki?p=GpeDependencyMap might help to identify the dependencies. If you build GPE software which is not listed there please add it to the wiki, it is editable by anyone.

The major part of the potential target devices for GPE will not have an Intel x86 compatible CPU which most developers usually use on their development workstations. This and the fact that our typical target device has very limited harware capabilities are the reasons why we need special mechanisms to compile GPE libraries and applications to run on our target devices. Depending on the situation and your personal preference there are several methods to choose. We describe the most frequently used ones here. The examples assume that you compile for a device with an ARM CPU running Linux.

For a simple and fast start crosscompiling a GPE application get a copy of the prebuilt crosstoolchain for GPE from linuxtogo.org. Currently this reference toolchain is built using the OpenEmbedded build system. It is updated from time to time to supply newer compilers and updated libraries. These toolchains are limited to some extend. Both the architecture of the computer the toolchain runs on and the architecture of the target system are fixed. Currently we have toochains wich run on Intel x86 based PCs running Linux and systems using an IBM PowerPC CPU running Linux. Both variants of toolchain create binaries for ARM CPU (StrongARM, Xscale, OMAP) based devices which are used on most mobile devices like PDAs. To install the prebuilt toolchain you need to have root privileges on the PC you install it to. The installation itself is very easy: Change to the root ("/") directory and unpack the toolchain there: $ tar xpjf sdk-package-archive.tar.bz2 Using the toolchain is easy as long as the software supports being crosscompiled properly. You need to have the compilers of the toolchain in your PATH environment. This is necessary to make sure all tools used for compiling the software find all the executable binaries shipped with the toolchain. To achieve this run: $ export PATH=/usr/local/arm/oe/bin:$PATH You can add this to your local .login or .bashrc file to have this setting in every shell you open. Before using the toolchain for compiling you need to set the PKG_CONFIG_PATH environment variable to tell the pkgconfig tool where to find the correct information about the libraries shipped with the toolchain. The environment variable needs to point to the pkgconfig of the toolchains library directory. Do this: $ export PKG_CONFIG_PATH=/usr/local/arm/oe/arm-linux/lib/pkgconfig/ If you have more than one location you want to get libraries from, use ":" to separate multiple paths. You should not put this setting into .basrc, because you won't be able to compile natively without changing PKG_CONFIG_PATH anymore. You are now ready to start building your first application for the ARM architecture. Compiling an application with the toolchain is very easy as long as all dependent libraries are part of the toolchain and crosscompiling works properly with the piece of software you intend to compile. The method to do this depends on the build tools which are used for this software. If the application is using autotools you need to pass some parameters to configure to tell it to create makefiles for crosscompiling. These parameters are the target prefix of the toolchain (in our case "arm-linux") and the destination prefix used on the target platform (usually "/usr"). Once configure created the necessary output files you can call make to start compiling. In most cases you just need to go to the source directory and run: $ ./configure --host=arm-linux --prefix=/usr $ make Of course you can add additional parameters to configure to influence the build process according to your needs. If you want to compile software from CVS you need to run the script autogen.sh to create some parts of the build framework first. If the script is missing almost any autogen.sh from GPE CVS should do the trick. If you need to compile one of the "classic" GPE applications not using autotools you need to pass the compiler and prefix to use to make directly. You need to set the variables CC to the compiler to use and PREFIX to the prefix for the software at least. If you want to build an ARM binary for Familiar Linux you would use: $ make CC=arm-linux-gcc PREFIX=/usr You can easily add software in the crosstoolchain or update existing ones. Compile and install it with /usr/local/arm/oe/arm-linux as PREFIX. If you update libraries using libtool it is a good idea to remove all *.la from /usr/local/arm/oe/arm-linux/lib.

Scratchbox is a very powerful virtual development environment which is able to build binaries for a different platform transparently and is even able to run these binaries in an emulated environment or by transfering them to a real device transparently. Scratchbox is available as packages for several distributions. For detailed information about installing Scratchbox refer to the Scratchbox project documentation. Apart from the Scratchbox setup crosscompiling applications in Scratchbox is the same process like compiling natively. The only thing you need to do before is to select a target machine definition created during the install process. The fact that Scratchbox is able to execute the target binaries transparently avoids errors caused by broken autoconf tests which try to build and execute a binary because this will fail using a normal crosstoolchain. In addition to this you can configure Scratchbox to run these binaries on a real target device. This makes it possible to test and debug them on the target hardware in a very comfortable way. This is very important if the software makes use of special hardware features not present on development PC or if you port applications to a new hardware platform. Scratchbox is very useful if you need libraries for native development which are incompatible with your host system (or each other). For some GPE applications which support the Hildon user interface from the Maemo project. This is very useful to switch from Hildon to plain GTK and back. You can do this by using Hildon inside of a native development target for Scratchbox and another target (or just your host system) for plain GTK.

Apart from the described methods you can always build your own toolchain, Debian crosstoolchain packages or use a User Mode Linux setup for crosscompiling. For a detailed description how to do this please refer to specialized documents.[ref]

After all these information about how to compile GPE it might be interesting to know where to find GPE and information about it.

The first thing to know about GPE sources is the location of the GPE main source repository. This one is located here: http://gpe.linuxtogo.org/download/source/ It contains the release packages of all pieces of GPE. As long as there is no good reason not to do so please choose the latest version of a package if you intend to use it. The GPE project makes use of the linuxtogo.org Subversion (SVN) to keep its sources. You can access latest sources either by using the svn command line tool or ViewCVS if you only want to take a look. If you do not have an account at linuxtogo.org you can check out GPE with anonyomous SVN access. Follow these example instructions: $ svn checkout svn://projects.linuxtogo.org/svn/gpe/trunk gpe_svn For a detailed description of the contents of GPE SVN repository see the section about the SVN below. To find out more about how to use Subversion check out the manual at http://svnbook.red-bean.com/.

Just continue reading this manual might be the best idea, but there are other sources for information available: The GPE website (http://gpe.linuxtogo.org) itself is currently not perfectly up to date, but it contains some additional information about some parts of GPE and some news about what is going on. It also contains information about how to get in touch with the developers and a nice screenshot gallery to find out how GPE looks(and looked) like. linuxtogo.org Wiki has much of information about GPE and related topics like the Angstrom distribution and Linux on all kind of mobile devices. It also contains a collection of user documentation for several GPE applications. Not everything is documented or obvious - if you need help or are curious about something do not hesitate to use our mailinglist ([email protected]). Because postings from not subscribed email addresses need to be moderated manually which takes a lot of time it is currently a very good idea to subscribe to the mailinglist before sending a mail to it.

The GPE CVS is separated into seven toplevel directories. base GPE core applications and libraries. extra Additional applications and libraries like multimedia and network. eyecandy Themes and wallpapers. games Game applications and data. html The project website and some documentation. marketing GPE marketing information like flyers and logo. documentation GPE documentation, manuals, this document. legacy Old, unfinished and unused bits. The base section contains a toplevel Makefile to build a whole GPE - don't try to use it, it is broken because of our move to autotools.