Adding Applications To OpenMoko The Right Way
myopenmoko at richip.dhs.org
Wed Aug 29 15:52:05 CEST 2007
You know ... someone should just take the following post and create that
page on the wiki. It should be a good enough skeleton framework to build
the documentation you need on. There are already the titles for what one
guy wants to see (the bunch of "how to"s). Mentioning the need for a
good working knowledge of autotools is good, too. Eventually someone
will fill in the blanks, put links to good autotools docs and tutorials,
etc. If the BB files are one of the most important sources, someone
might post a link to a good page documenting bitbake recipe markup.
There was a guy here before who was a documentation nut. Any idea that
came up on the list would end up on the wiki somehow. That's how some of
the good pages on the wiki got started.
I don't know how to use wikis much.
On Wed, 2007-08-29 at 15:29 +0200, Robert Schuster wrote:
> 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).
> > 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
More information about the openmoko-devel