Development Environment
The development environment for maemo running on the desktop is called maemo
SDK[54]. It will only install and run on a Linux operating system. Supported Linux
distributions for maemo SDK are currently Debian and Ubuntu, but installing maemo
SDK is also possible for other distributions. On other operating systems such as Windows,
a VMWare image[80] can be used to provide a working Linux environment.
8.1 maemo software development kit
The maemo SDK creates a sandboxed maemo development environment on a
GNU/Linux desktop system largely built on a tool called Scratchbox[66]. In most
ways this environment behaves like the operating system on the device but with added
development tools. This means that the development process is very similar to normal
desktop GNU/Linux and the kinks of embedded development, such as cross-compiling,
are handled transparently by Scratchbox.
8.1.1 Hardware architectures
Maemo SDK comes with two environments for two architectures. x86 is used for
native performance and better tool support though native execution without need for
emulation. ARMEL is used for working with the actual device’s architecture. Both
have their advantages and roles in maemo development. It is important to understand
that maemo SDK actually provides these two environments as preconfigured targets
inside a working Scratchbox installation. This is explained in detail later.
Generally in active development the x86 environment is used because it provides
practically the same performance as normal GNU/Linux applications. Also, although
the underlying architecture is different from the actual device, programs usually behave
exactly as they would when compiled and run on ARMEL. As stated before, many tools
are available only for the x86 environment.
When an application is running fine in the x86 environment the next step is to
compile it for the ARMEL architecture. The process for compilation and packaging is
exactly the same as in x86, albeit a bit slower because some of the required software
is emulated. The developer needs not to concern with cross-compilation. This is the
main rationale for maemo SDK to use Scratchbox in the first place.
The applications compiled in ARMEL environment can be run straight on the device.
Additionally, it is possible to run some of the applications inside the ARMEL environment
in maemo SDK. This is possible because of the automatic emulation maemo
SDK provides. The emulation is not complete and things like multithreading will cause
problems, so actual testing must be done on the device.
Using emulation for the whole development process may not sound ideal because
of the effect on performance. That’s why even when in ARMEL environment, native
performance is achieved with Scratchbox by internally using the host computer’s tools
without emulation when possible. For example, compilation on ARMEL environment
is actually done by an x86-ARMEL cross-compiler, but Scratchbox hides the details so
that the developer can execute GCC like on any GNU/Linux system.
8.1.2 Development on maemo SDK
The maemo SDK provides all of its development tools inside Scratchbox. Also the
Hildon Desktop is started with a single command af-sb-init start inside Scratchbox.
However, the Hildon Desktop needs a secondary X server of proper size and bitdepth
to be displayed on.
As an exception to the rule, the X server such as Xephyr[78] must be started on the
host Linux environment instead inside Scratchbox. The use of Xephyr is described in
the maemo SDK tutorial[36].
8.1.3 Development tools on Scratchbox
As the Scratchbox environment is practically a full GNU/Linux system, it includes the
standard GNU/Linux development tools. Debugging is done with tools like GDB[13],
valgrind[76], ltrace and strace[68]. Performance profiling can be done with tools like
htop[31], oprofile[61] and time and compiling with the GCC toolchain. Some of these
tools offer graphical user interfaces which can also be used. Of course this isn’t a
comprehensive list of the tools and if the tools shipped with the SDK don’t suit to
needs or personal preferences, most utilities can be easily run practically unchanged in
Scratchbox.
The Maemo Tutorial[36] is a good introduction to development using Scratchbox
and debugging tools are described in depth in The Maemo Debugging Guide[42].
8.1.4 Testing and debugging on device
Even though Scratchbox is quite accurate in emulating a full target environment on the
device, it isn’t 100% identical. Especially applications that make use of the device’s
special hardware can behave differently on the device than on Scratchbox. They even
may not work at all. Fortunately testing the software on device is quite straightforward
using either SSH or a tool called sbrsh to run target binaries on the device transparently
from Scratchbox.
The CPU Transparency how-to[6] has instructions for getting started with sbrsh.
SSH server and client for maemo can be downloaded from maemo web site[48].
8.1.5 Scratchbox under the hood
Scratchbox is maemo SDK’s cross-compiling environment. The default Scratchbox
installation works as-is under most conditions, but some details are good to know for
more specialized usage.
The target inside Scratchbox contains a root file system that is being worked on.
When a new target inside Scratchbox is created, a toolchain must be specified for it.
Using this toolchain, applications are built for the target. Examples of a target are X86
and ARMEL which are provided by the maemo SDK on top of Scratchbox.
Host tools are native to the host provided for convenience and speed. They are
always preferred over target tools and transparently for example cross-compile applications
to the target architecture. Host tools consist of devkits and toolchains.
A toolchain provides the minimal set of tools for compiling binaries for the target.
One and only one toolchain must be selected for every Scratchbox target.
CPU transparency methods take care of running the applications on an emulator,
target device or directly on the host transparently to the user. The available CPU transparency
methods come from a special devkit called cputransp. For each of maemo
SDK’s predefined targets a CPU transparency method is selected and defined.
A toolchain is a collection of tools used to produce binaries for the target environment.
In addition to a compiler (gcc) it contains a linker (ld) and other binutils such as
strip, objdump and strings.
A devkit is a collection of tools native to the host. A toolkit can be selected or
disabled for a target. An example of a devkit is doctools devkit, which provides tools
(like doxygen) for building documentation.
A rootstrap is a root file system for the target device. Maemo SDK provides root
file systems for both targets (X86 and ARMEL) inside Scratchbox. Note that the user’s
home directory is shared for all targets. The /tmp directory is shared for all targets and
also with host.
From Scratchbox’s point of view, Maemo SDK is a set of preconfigured targets and
root file systems. One set is provided for both X86 and ARMEL architectures on top of
a working Scratchbox installation.
More Scratchbox information can be found at Scratchbox’s web site[66].
8.2 Packaging, deploying and distributing
For installing and managing application packages maemo uses the popular Debian
package management system. From the user’s perspective this is quite invisible as
the package management is done using the Application Manager. Under the hood it
presents a flexible package framework which enables developers to easily create installable
and manageable packages without having to concentrate on the actual implementation
details of the management.
8.2.1 Deb installation packages
The Debian package management system uses deb-packages which, in addition to files
that will installed, consist of meta data describing the package, dependencies to other
packages and optional installation and removal scripts. The process of creating the
packages is fortunately made quite simple by various package development tools.
The process of creating packages is described in the Making Application Packages
document[56].
8.2.2 Package repositories
The package management system makes use of package repositories, which are essentially
web or FTP sites that contain packages and some information about them. It isn’t
mandatory for a package to exist in any repository, but it has significant advantages:
user can easily update packages, other developers can use the packages as automatically
installable dependencies and the repository’s packages can be found using Application
Manager.
Information for working with repositories can be found in the Debian Repository
HOWTO[8].
8.2.3 One-click-install
Maemo also has a option to create installation instruction files that enables the users to
install applications simply by clicking a link on a web site. The .install files contain
required repository and package names. The format of these files is really simple and
it’s described in Hildon Application Manager documentation[28].
8.3 Programming languages
Currently C is the only official programming language for maemo. But thanks to the
community, unofficial support exist for several other languages. To name a few, the
SDK itself compiles C++ and by adding hildonmm bindings[29] Hildon applications
can be created the C++ way. Python scripting language also has a good support in form
of pymaemo[63] and Ruby bindings are in the works[65], not to forget Mono[58]. For
Java support, JaliMo[33] is an interesting project to track.
No comments:
Post a Comment