Adding Applications To OpenMoko The Right Way

[Emre Turkay]

I agree with Robert on the simplicity of the bb files and ease of the
compilation process with openembedded. I think the real confusion
caused by the openmoko development over openembedded. When someone
read the openembedded user manual and follow the step by step
processes, s/he sees that it doesn't work, even the files and
directory structures differ.

I would love to see a detailed tutorial written for the application
development with openmoko and how it sits on top of openembedded,
which includes the headings
- "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."
Of course it all depends on someone who has time but maybe FIC folks
can give a head to this work.

I think it will take time for someone to master all the details of
openmoko/openembedded development tools and I believe a document/wiki
page with a quick start/howto like structure will give a boost to the
openmoko applications/developments. Come on folks there are about one
thousand people out there who has neo and probably with some level of
programming background (not including ppl working with qemu).

emre

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
>
>
>