Developing software using the maemo SDK is quite similar to using a Symbian OS SDK. You write, compile, and run the code, usually using an Integrated Development Environment (for example, carbide.c++ for S60, Visual Studio for Windows Mobile, or ESbox + Eclipse for the maemo platform). The Symbian OS SDKs include a phone simulator, which is a Windows executable capable of running Symbian OS software on an x86 workstation. The Windows Mobile SDK kits also include similar phone emulators and are capable of running .NET Compact Framework software.
The maemo SDK also enables running maemo software on the development workstation, but the approach is different. There is no single program to simulate the target device. Instead, Scratchbox is used to run a functional maemo platform instance inside the development workstation.
The work horse of maemo development is Scratchbox, a cross-compilation toolkit. The fundamental idea is that Scratchbox works as an independent "sandbox" inside your GNU/Linux workstation. This sandbox contains all the required compilers, files, development headers, and libraries needed to develop software for a maemo device.
Sandboxing has several benefits. Both the GNU/Linux workstation (host system) and the maemo device (target system) run on GNU/Linux-based OS so you should make sure that libraries of the host system do not cause problems when compiling binaries for the target device. The scratchbox also supports several 'targets' (but unfortunately only one target can be active at a time). Usually one target is for developing for x86 with the whole runnable maemo platform and another target for creating the binaries for the actual device. You can also have targets for different maemo platform release versions (for example, maemo 2.0 'mistral', maemo 3.0 'bora', maemo 4.0 'chinook', maemo 4.1 'diablo', etc.).
For the developer, the scratchbox looks like a separate GNU/Linux operating system inside the actual GNU/Linux workstation. The developer can 'log in' to the scratchbox, and everything outside the scratchbox becomes 'invisible', that is, the directory /usr/bin inside the scratchbox contains different files than /usr/bin of the actual GNU/Linux workstation.
Scratchbox is a completely different concept than VMWare. VMWare creates a virtual machine inside your real machine. Scratchbox uses wrappers and creates boundaries within the file system to prevent unwanted access to the host GNU/Linux workstation's files.
Before learning what Xephyr is and what it does, it is essential to understand the basics of the X Window System.
X Window System provides the basic framework for building GUI environments: drawing and moving windows on the screen and interacting with a mouse and/or keyboard.
The X Server in the X Window System gathers user input (keyboard, mouse) and passes it to X aware applications, called X clients. The X Server also provides a way for X clients to display graphical output. The image below illustrates a very simplified picture of this.
Communication between the X Server and X clients are network transparent. This means you can run a Web browser on a different computer, which then uses the X Server on your workstation.
Why use Xephyr?
The target maemo device (Nokia 770, Nokia N800, or Nokia N810) will have an X Server running on it, just like your GNU/Linux workstation. The screen resolution for the Nokia 770, Nokia N800, and Nokia N810 is 800 x 480 pixels, while your GNU/Linux workstation could have any resolution, for example, 1024 x 768, 1600 x 1200, or 1440 x 900 pixels.
Xephyr is started, its window size is set to 800 x 480 pixels, and the maemo platform inside Scratchbox is told to use Xephyr as its X Server. This way it is possible to have a single 800-x-480-pixel window in the GNU/Linux workstation desktop, which displays the maemo content.
It doesn't matter if Xephyr is run outside the Scratchbox, since the Scratchbox affects only the file system. Sockets and shared memory are accessible both from the in and outside of the Scratchbox.
For the end user, binary packages (that is, .sis packages in Symbian OS) are the easiest way to install software to the device. Unfortunately distributing binary packages is not a good solution if you want the widest possible audience for the open-source software. There are several different Unix-style operating systems (for example, GNU/Linux, OpenBSD, HP-UX, Solaris) and different distributions of these operating systems, which makes building binary packages for every operating system and distribution practically impossible, at least for a single developer or small development team.
Several GNU/Linux distributions (Debian, Ubuntu, Red Hat, maemo) distribute software as binary packages available from central repositories. The original developer is usually not responsible for maintaining the binary package for a certain distribution.
The graphical integrated development environments hide much of the complexities of building the software and making distributable packages (source code or binary). Nevertheless, you should know some basics about the underlying build system, as it helps you to diagnose possible problems which might occur, especially when porting software to the maemo platform.
When a source code package is released as defined in "GNU coding standards", chapter 7, there is a standard routine for installing the software it contains. So whether compiling the sources in the HP-UX server, in the GNU/Linux workstation, or inside the Scratchbox for a maemo Internet Tablet, this routine is the same.
The following example is just an imaginary case.
$ tar -zxvf example-0.10.tar.gz
$ cd example-0.10
./configure.
This is a shell script which examines the system where the source
package is going to be built. It checks, for example, that required
headers, libraries, and other tools are available, library versions,
and locations in the file system. Different parameters (like the
installation directory) can also be given to the configure script.
~/example-0.10$ ./configureor
~/example-0.10$ ./configure --prefix=/home/user --disable-logging
README file
which gives more instructions. Sometimes an autogen.sh
script should be run first. Usually this is the case when the sources
are downloaded as a snapshot from version control.configure
command fails, the reason must be examined and fixed. Then the configure
command must be run again. Failures are commonly caused by unmet dependencies
(missing or wrong version libraries, development headers, etc.)make.
Begins the build process.make install.
After a successful build, the software is installed with this command.
It copies the binaries and datafiles to directories specified at the
'configure' stage.The routine above requires that a working toolchain is available in the system.
In the GNU/Linux operating system (and, consequently, in the maemo platform), the GNU toolchain provides the complete set of compilers and tools required for building software from sources.
The GNU toolchain includes:
The GNU build system tries to solve a problem: The original developer
knows nothing about the system where the source code is going to be
compiled.
Without autotools there wouldn't be a configure
script to run *; instead,
every user would have to manually edit the source and configuration
files.
The GNU build system supports several compilers, operating systems, and environments, and therefore the usage may seem fairly complicated at first.
configure script mentioned above
because the script would be complex and grow very large. For example,
the configure script for the monotone-0.35 version
control system is 474KB in size.GNU
Autoconf tool, which is a part of the GNU build system, is
used to create the configure script. The
developer writes a configure.ac* text file, which is then
processed by the autoconf, generating the
configure script. The configure.ac
file contains, for example, software name and version, dependency
checks (is library x, version y available), and so on.
configure.ac
was earlier named as configure.in, but that
naming has been deprecated. You might still see it in older source code
packages.For more information, see the Wikipedia entry about Autoconf.
In addition to configure.ac, the developer
writes one or more Makefile.am files. These
files define which source files are compiled and how, where the
binaries and datafiles should be installed, and so forth.
GNU
Automake is a tool which processes these Makefile.am
files, and generates Makefile.in
files.
When the configure script is run, it
processes these Makefile.in files and creates
the actual Makefile
files. These Makefiles are then used by the make,
as mentioned earlier.
For more information about autoconf and automake, see http://www.openismus.com/documents/linux/automake/automake.shtml.
The software developer:
The user who wants to install the software:
The default IDE for the maemo development is Eclipse with ESbox plug-in.
Eclipse is an open-source software framework, commonly used as an Java IDE. It is extendable through plug-ins and support for other languages than Java has been added that way.