Maemo is the software environment for the Nokia Internet Tablets. Here are some notes and hints to bear in mind about developing GPE applications for the Maemo environment.

Table of Contents

Contents

  1. Table of Contents
  2. Maemo releases
    1. Package dependencies
  3. Building for Maemo
    1. Building using MUD
    2. Building using existing package
  4. Conditional code

Maemo releases

Building and releasing GPE applications for Maemo is currently handled by GrahamCobb. When it is time to release a GPE update for GPE (typically every 6 months or so), Graham uploads the release candidate packages to the Maemo Extras-devel repository where they are available for testing for some time (typically a couple of weeks). Once they have been in extras-devel for a while he promotes them to the Maemo Extras repository, where they are easily available to all Maemo users.

Graham builds the entire set of Maemo-compatible GPE packages forarmel from the SVN automatically on a regular basis and makes them available in his daily build repository. These packages are mainly intended for use by the GPE development community. They are not tested in any way.

Graham does not build GPE packages for Maemo i386, but packages are created in the Maemo extras-devel repository by the autobuilder. If you need an i386 version of the latest SVN code you will need to build it yourself (see below).

GPE for Maemo currently includes the following user-installable packages:

and the following automatically installed packages:

Package dependencies

In order to simplify things for users, the GPE packages all use a version number derived from the GPE release (currently 2.8) and the date of the SVN sources they are built from. This simplifies support but it means that, in particular, library package versions do not reflect ABI changes. It is also the case that sometimes the library files do not support proper library versioning. This should be fixed in the future but it is the reality of the situation today.

For that reason, all GPE package dependencies are set up to be >= the current version. So, for example, gpe-calendar version 2.8+maemo+svn20080502-1 depends on libeventdb2 >= 2.8+maemo+svn20080502. What this means, is that if one of the applications is upgraded, all the libraries it depends on will be upgraded (although not the other way around).

This is a compromise between making the dependencies too weak and so strong they make it hard to ever do an upgrade.

Building for Maemo

It is, of course, possible to build components directly from the SVN sources. But this requires having several dependencies already installed, and it may create multiple output files, which have to be copied to the tablet for testing. It is often convenient to build packages, which can be copied to the tablet and, when installed, put the files in the right places.

Currently the SVN does not contain all the patches needed to build Maemo packages. The best way to build Maemo packages of the applications is to use MUD.

Building using MUD

Maemo Unofficial Debs is a tool to make it easy to build maemo packages from an upstream source, optionally with a number of patches. To find out more about MUD see the project pages: http://mud-builder.garage.maemo.org/. However, here is a summary of how to use MUD to build a GPE component, say gpe-calendar. All these steps occur inside your scratchbox environment.

  1. Install MUD. 
     cd
 svn co https://garage.maemo.org/svn/mud-builder/trunk mud-builder
    This will create a directory ~/mud-builder which will contain the MUD files.
  2. Create "mud" as an alias 
     alias mud=~/mud-builder/mud
    You will probably want to add this line to your ~/.profile file so it is defined each time you enter scratchbox.
  3. Build gpe-calendar 
     mud build gpe-calendar

    This will then build gpe-calendar but will first build all the dependencies, and all their dependencies, etc. All the debian packages will be created in ~/mud-builder/upload/*.deb and can be copied to your internet tablet for installation.

Once you have built gpe-calendar for the first time, you can tell mud not to bother to re-build all the dependencies, and just build the specified package, by using the -d option: 

mud -d build gpe-calendar

This will fail if the dependencies are not installed in your scratchbox environment. But a successful build will leave the dependency packages installed (unless you remove them, for example using using dpkg -r).

MUD builds sometimes fail if a mud get command has been used (see below). If the build fails, try removing all the build directories using: 

mud -a clean

But be aware this will delete ALL files in ALL build directories. Make sure you didn't have your edits to a source file in one of the build directories.

This process does not build from the SVN HEAD. In fact, it fetches sources from SVN using a date specified in the mud package file, which will often be some months ago! The mud package file for gpe-calendar is ~/mud-builder/packages/gpe-calendar.xml. In that file is a line saying something like: 

date="20080114"

In order to build from SVN HEAD make the date a future date (e.g. "20100101"). Mud fetches the sources from SVN as at the 00:00 on the specified date (so if the date is today's date it will get changes as at midnight last night).

In order to build your own changes, you need to tell MUD to fetch the files for the package but not build it. These are the steps:

  1. Make sure there are no previous build files 
     mud clean gpe-calendar
  2. Fetch the files from SVN 
     mud -d get gpe-calendar

    Note: if you leave off the -d, MUD will first build all the dependencies and then fetch the files. This process fetches the files from SVN and applies the patches that MUD has been told to apply. For GPE these are not normally patches to source files but patches to files in the debian directory and to configure scripts and Makefiles.

  3. Change to the build directory. MUD will display the build directory spec in the output from the mud get command. It will be something like: ~/mud-builder/build/gpe-calendar/gpe-calendar-2.8+maemo+svn20080114-1/

  4. Make your edits to the files in the build directory (or copy the edited files from somewhere else, for example if you have an SVN working copy somewhere else).
  5. Tell MUD to build the package from the files already in the build directory: 
     mud compile gpe-calendar
    If successful, this creates a package file in ~/mud-builder/upload which can be copied to the tablet and installed.
  6. The last two steps can be repeated as many times as necessary.

  7. MUD provides a neat trick to create a patch matching your changes. The MUD build directory is actually an SVN working copy directory where the "repository" is not the real GPE repository but a hidden directory in your scratchbox tree containing a copy of the files extracted from the real SVN. In order to see what edits you made you can use svn diff. For example, if you had edited event-ui.c you could create a patch file for it using: 

     svn diff event-ui.c >~/event-ui.patch

    The only thing to bear in mind is that this fake SVN also knows about the patches made by MUD during the mud get operation. But these are not normally to source files. But remember that ALL files in the build directory (including your edits) will be deleted if you use the mud clean command.

This process allows you to develop changes in the MUD build directory and build test packages. But do not forget to save your changes outside the MUD build tree before doing a mud clean. Personally I do not make edits in the MUD build directory itself: I have another directory outside the mud-builder tree where I make the edits and I copy the edited files into the build directory when I want to build a test image.

You also do not have to actually copy the whole rebuilt debian package and install it. You can, of course, copy files to the tablet directly out of the build tree (for example, gpe-calendar is the program binary). This has the advantage that normally the files in the build tree are not stripped and contain debugging symbols, whereas the binaries in the packages are stripped.

Note that packages created this procedures should not be made available to others: they will generally have the same name and version numbers as "official" packages and are likely to cause confusion. If you want to make the packages available to others please make sure you change the package version string to be clear these are your modified packages. Doing that is beyond the scope of these instructions but take a look at the .xml file in the packages directory.

Building using existing package

MUD is a useful tool for managing builds and for managing patches which need to be applied to upstream files. However, it is quite complex if all you want to do is either to just build a package or to make a small change and rebuild a package.

An alternative is not to use MUD and the SVN sources directly but to use an already existing source package. Each GPE package in the repositories (in Extras, in Extras-devel or in Graham's repositories such as the daily build repository) includes a source package as well as binary packages. To build from this source you use the normal debian procedure:

  1. Make sure you have deb-src lines in your /etc/apt/sources.list file. For example, this is the line to specify that apt should fetch sources from the Maemo Extras repository: 

     deb-src http://repository.maemo.org/extras/ chinook free non-free
    If you have changed /etc/apt /sources, update: 
     apt-get update
  2. Fetch the source: 
     apt-get source gpe-calendar

    This will fetch the package files into the current directory and expand the sources in a subdirectory called something like gpe-calendar-2.8+maemo+svn20080114

  3. Install the build dependencies: 
     apt-get build-dep gpe-calendar
  4. Change directory into the source directory and make your source file edits.
  5. Rebuild the package: 
     dpkg-buildpackage -rfakeroot -uc -b
    This will put the created .deb file in the parent directory. It can then be copied to the tablet and installed.

Note that packages created this procedures should not be made available to others: they will generally have the same name and version numbers as "official" packages and are likely to cause confusion. If you want to make the packages available to others please make sure you change the package version string to be clear these are your modified packages. Doing that is beyond the scope of these instructions -- see the man page for dpkg-buildpackage.

Conditional code

As with all the GPE target environments, it is best to avoid conditional code for Maemo if possible. However, the following symbols are available for code which needs to be conditional for Maemo:

These symbols are typically used as follows: 

#ifdef IS_HILDON
      gint as =
         hildon_number_editor_get_value (HILDON_NUMBER_EDITOR (s->alarmspin));
#else
          gint as =
         gtk_spin_button_get_value_as_int (GTK_SPIN_BUTTON (s->alarmspin));
#endif

or 

#ifdef IS_HILDON
#if HILDON_VER > 0
#include <hildon/hildon-caption.h>
#include <hildon/hildon-number-editor.h>
#include <hildon/hildon-time-editor.h>
#include <hildon/hildon-date-editor.h>
#include <hildon/hildon-note.h>
#else
#include <hildon-widgets/hildon-number-editor.h>
#include <hildon-widgets/hildon-time-editor.h>
#include <hildon-widgets/hildon-date-editor.h>
#include <hildon-widgets/hildon-note.h>
#endif /* HILDON_VER */
#endif

GpeMaemoTips (last edited 2008-06-10 11:26:10 by 84-217-168-63)