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 <[EMAIL PROTECTED]> 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
signature.asc
Description: OpenPGP digital signature
