Preparation

The commandline program

Store the following more or less standard hello world code in hello.c

#include <stdio.h>
int main()
{
printf ("Hello World\n");
return 0;
}

Compiling it the wrong / easy way

Assuming your current working directory is /home/moko, and that you stored the code in /home/moko/hello.c it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

Testing it

Assuming you have followed Setting up USB connection and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice Hello World, btw. the default root password is blank, just press return.

GDK the Wrong / Easy Way

Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Then copy and run as in the original hello world command line program above.

Why was it the wrong way?

Openmoko provides a precompiled Toolchain package for that. It also comes with some scripts that make your life much easier. Besides, you don't need OpenEmbedded to build applications. If you do want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for Openmoko.

The Right Way: Using the gnome build system

Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

Creating the necessary documentation files and directory structure

First of all go into the directory you want to be the topmost application of yout new application, and create the following files:

AUTHORS

A list of all authors that took part in developing this project

COPYING

The copyright notice. Favourably the GPL

INSTALL

This file should contain the information how to build and install this program

README

This file should contain all important information about the program including what the program was written for.

NEWS

The name of this file should be self-describing

TODO

The wishlist of your project

Changelog

A list of the major changes to your project

I remember that some of these files were mandatory - it's better create them all

Then create a directory named 'src - and copy the source code of the program there.

The configuration of the autotools

What is to be said to this section is that I included some requirements like gnome-vfs to the requirements not because our application actually needs these packages but because it was very hard to find out how to do so - and I therefore wanted to document how to add them.

If anybody doesn't like this approach - feel free to edit this wiki.

autogen.sh

This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

! /bin/sh

Most if not all of the contents of this file was taken from the openmoko

src/Makefile.am

This file is a template Makefile that when filled with life by the configure script will compile our code.

The most important step here is to tell which files our program consists of.
AM_CFLAGS = $(DEPEND_CFLAGS) -Wall

AM_LDFLAGS = $(DEPEND_LIBS)

LDADD = $(LIBINTL)

bin_PROGRAMS = hello
hello_SOURCES = hello.c

Internationalization

Now the instructions on how to generate a gnome build system for our application should be nearly working. In order to generate a .tar.gz- archieve of the complete project that contains the full build system just type the following two lines:
./autogen.sh
make dist

What still has to be done is internationalization: A very fine feature of open-source software is that it is possible to translate them to nearlly all languages - and normally sooner or later somebody will have done this.

The only thing that has to be done so our program can easily be internationalized is the following:

get a gettext.h file and copy it to your src directory

add an #include gettext.h to all source files that contain text that can be translated.

add an _( in front of all strings that might be translated and an ) after the string.

Our source file looks now like this:

include <stdio.h>

include "gettext.h"

int main()
{
printf (_("Hello World\n"));
return 0;
}

Building our new package

I never used the offical openmoko toolchain, so no documentation for this for now - even if I don't think there is any magic there. Since the documentation of the MokoMakefile is rather good, I will document this approach - that I actually used - neither.

Preparation

The commandline program

Store the following more or less standard hello world code in hello.c

include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

Compiling it the wrong / easy way

Assuming your current working directory is /home/moko, and that you stored the code in /home/moko/hello.c it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

Testing it

Assuming you have followed Setting up USB connection and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice Hello World, btw. the default root password is blank, just press return.

GDK the Wrong / Easy Way

Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Then copy and run as in the original hello world command line program above.

Why was it the wrong way?

Openmoko provides a precompiled Toolchain package for that. It also comes with some scripts that make your life much easier. Besides, you don't need OpenEmbedded to build applications. If you do want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for Openmoko.

The Right Way: Using the gnome build system

Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

Creating the necessary documentation files and directory structure

First of all go into the directory you want to be the topmost application of yout new application, and create the following files:

AUTHORS

A list of all authors that took part in developing this project

COPYING

The copyright notice. Favourably the GPL

INSTALL

This file should contain the information how to build and install this program

README

This file should contain all important information about the program including what the program was written for.

NEWS

The name of this file should be self-describing

TODO

The wishlist of your project

Changelog

A list of the major changes to your project

I remember that some of these files were mandatory - it's better create them all

Then create a directory named 'src - and copy the source code of the program there.

The configuration of the autotools

What is to be said to this section is that I included some requirements like gnome-vfs to the requirements not because our application actually needs these packages but because it was very hard to find out how to do so - and I therefore wanted to document how to add them.

If anybody doesn't like this approach - feel free to edit this wiki.

autogen.sh

This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

! /bin/sh

Most if not all of the contents of this file was taken from the openmoko

src/Makefile.am

This file is a template Makefile that when filled with life by the configure script will compile our code.

The most important step here is to tell which files our program consists of.
AM_CFLAGS = $(DEPEND_CFLAGS) -Wall

AM_LDFLAGS = $(DEPEND_LIBS)

LDADD = $(LIBINTL)

bin_PROGRAMS = hello
hello_SOURCES = hello.c

Internationalization

Now the instructions on how to generate a gnome build system for our application should be nearly working. In order to generate a .tar.gz- archieve of the complete project that contains the full build system just type the following two lines:
./autogen.sh
make dist

What still has to be done is internationalization: A very fine feature of open-source software is that it is possible to translate them to nearlly all languages - and normally sooner or later somebody will have done this.

The only thing that has to be done so our program can easily be internationalized is the following:

get a gettext.h file and copy it to your src directory

add an #include gettext.h to all source files that contain text that can be translated.

add an _( in front of all strings that might be translated and an ) after the string.

Our source file looks now like this:

include <stdio.h>

include "gettext.h"

int main()
{
printf (_("Hello World\n"));
return 0;
}

Building our new package

I never used the offical openmoko toolchain, so no documentation for this for now - even if I don't think there is any magic there. Since the documentation of the MokoMakefile is rather good, I will document this approach - that I actually used - neither.