Adding Applications To OpenMoko The Right Way

Robert Schuster r.schuster at tarent.de
Wed Aug 29 15:29:25 CEST 2007


Hi,
AFAIK OpenMoko will employ someone to fix OE- and OM- related issues.

Maybe this gal/guy will also provide the information for 3rd developers
you want:
> - "how to port an already existing autotools project to openmoko",
> - "how to extend an already existing openmoko application",
> - "how to extend the openembedded specific code",
> - "how to write new openmoko applications",
> - "how to commit your changes/additions to the openmoko & openembedded
> repositories."

Still much of the above information can be learned by looking at the BB
files. However think about this: If you don't have autotools knowledge
you will have a hard time understanding e.g. autotools.bbclass. It is
all very complex because it can achieve so much.

There is an OE manual somewhere on openembedded.org which the OE devs
can edit. I would love to see this being turned into a real wiki (with
anonymous write access like wikibooks). Then we can probably write the
most comprehensive book about free software-based embedded software
development. Imagine a book that covers aspects from:
- diff/patch, quilt
- cvs/svn/hg/git/mtn usage
- makefile/scons/cmake
- autoconf, automake, libtool
- linux kernel compilation
- uboot, redboot, ...
- gnu toolchains
- bitbake, openembedded
- building & packaging c/c++/perl/python/ruby/java/... programs and
their libraries (and runtimes)

(This being an *incomplete* list of technologies one should have
understanding of.)

Such a book would be a jewel for the community. ATM one can get this
only by buying many separate books (some of those are even under open
content licenses).

Regards
Robert

> On 8/29/07, Robert Schuster <r.schuster at tarent.de> wrote:
>> Hi Jim, hi list,
>>>>> people who do not understand the OE setup
>>>> Start with fixing that :)
>>>>
>>> I know that was somewhat meant in jest, but as mentioned at current this
>>> is pretty frustrating.
>>>
>>> So you really think that every person who would like to develop for
>>> OpenMoko should be able to understand the OE setup?  Please tell me how
>>> understanding the build system helps them to write their application.
>> You dont need to understand the OE setup to 'write an application'. You
>> need to understand it, if you want to package it and put it on the root
>> image.
>>
>>> And for the converse: how hard is it really for someone, you for
>>> example, to write a step-by-step set of instructions to explain how
>>> someone with an application already written may get it on to the neo
>>> with the minimum of their effort?
>> AFAIK the EXTRA_RDEPENDS_DISTRO thing works (remember to rebuild
>> task-base) but is considered unclean. So if breaking the rules and
>> possibly creating a too large image is ok, that is your solution. (Btw:
>> You can get around the size limitation a bit if you set up your Neo to
>> boot from the SD card).
>>
>>> Wanting people to know everything about everything is a noble idea but
>>> when those people have limited time resources then spending that time in
>>> places other than where they are best qualified is nothing short of
>>> wasteful.
>> For around 1.5 years I am playing with OpenEmbedded from time to time. I
>> still don't get many things but it is getting better. However the reason
>> for this slow progress on my side isnt because OE is shit. It is because
>> the functionality it delivers is unbelievable big: OE allows you to
>> build a complete GNU/Linux distribution from scratch with only one
>> command (e.g. bitbake openmoko-devel-image). One person can do what
>> would otherwise require a strong development team (think of all the
>> different roles involved in the Debian packaging process). Moreover you
>> cannot only build a GNU/Linux for a limited set of devices (like
>> OpenWRT/FreeWRT). You can target nearly everything that is supported by
>> GNU Toolchains, Bootloaders and Linux Kernels (and that is a lot).
>>
>> On a similar topic: People are mourning about the complexity of the
>> autotools for ages but if you look at the BB files of packages using
>> them you will see that they are usually the smallest. All of those
>> handwritten makefiles and uberbuild systems require some special
>> treatment and often need to made aware of crosscompiling.
>>
>> In your own interest you should spend time in learning at least some
>> basics of OE. The time is invested very well.
>>
>> Regards
>> Robert
>>
>> --
>> tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
>>
>> Heilsbachstr. 24, 53123 Bonn    | Poststr. 4-5, 10178 Berlin
>> fon: +49(228) / 52675-0         | fon: +49(30) / 27594853
>> fax: +49(228) / 52675-25        | fax: +49(30) / 78709617
>> durchwahl: +49(228) / 52675-17  | mobil: +49(171) / 7673249
>>
>> Geschäftsführer:
>> Boris Esser, Elmar Geese, Thomas Müller-Ackermann
>> HRB AG Bonn 5168
>> Ust-ID: DE122264941
>>
>>
>>
> 

-- 
tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH

Heilsbachstr. 24, 53123 Bonn    | Poststr. 4-5, 10178 Berlin
fon: +49(228) / 52675-0         | fon: +49(30) / 27594853
fax: +49(228) / 52675-25        | fax: +49(30) / 78709617
durchwahl: +49(228) / 52675-17  | mobil: +49(171) / 7673249

Geschäftsführer:
Boris Esser, Elmar Geese, Thomas Müller-Ackermann
HRB AG Bonn 5168
Ust-ID: DE122264941

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20070829/2ec52403/signature.pgp


More information about the openmoko-devel mailing list