Hi, On Wed, 2008-04-16 at 13:24 +0100, Michael 'Mickey' Lauer wrote: > I have been requested to comment on our choice of build tools, specifically > OpenEmbedded. Unfortunately most of the statements people have approached > us with are not based on technical problems, but rather a vague sense > of uncertainty and doubt, which it is hard to argument against. > Anyway, let us take this opportunity to clean up some things and reply based > on facts and technical arguments.
I'll also reply to some of these questions since sometimes a different perspective can help... > Now the first bunch of questions: > > >---1 "The openwrt build system is much easier to use than OpenEmbedded" > >Can Openmoko switch to the openwrt build system? "easier to use" is a very subjective and it depends a lot on your background. If you're used to makefiles you'd love buildroot but if you don't understand makefiles its more of a nightmare. OpenEmbedded was written to allow various separate build systems and projects pool their development efforts and expertise into one place. To do this it has to have good abstraction and distinction between "machine", "distribution", "recipe" and other metadata. OpenEmbedded was written from scratch to do this and its safe to day that nothing else in the market has this capability. The downside is this brings in a certain level of complexity rather than a single purpose build system. Lets say a Openmoko suddenly decide to build an AVR based phone. How easy is it to add that to the openwrt build system vs. OE? How easy is it to try out a different libc? You find running "magicspeedup" on all the system binaries make the system 400% faster, how easy can you add that to OE to do automatically compared to build system X? Openmoko leaped ahead at the start in a number of ways by benefiting from the hard work already done in OE to make working embedded images. This isn't something you realise until you try to move to some other system and find all the work you took advantage of in OE has to be done from scratch elsewhere. > >---2 "building with a cross-compiler is wrong, builds should be done > >natively in an emulated (qemu) arm environment" > >Can Openmoko switch to compiling arm binaries 'natively' in a qemu > >environment, like Ubuntu Mobile? I think its important to differentiate between a development environment and a build system here. OpenEmbedded is a build system and integration tool through and through. Yes, you can use it as a development environment but it wasn't designed for that. Some day it may be directly usable as a development environment and this is something I personally have worked on and will continue to do so but at present its not end user ready for that IMO. So what are the options for a development environment? I'd strongly suggest people look at Poky's IDE plugin for Anjuta, its standalone toolchain and SDK and/or its native SDK images. This gives you the qemu environment if you want it with either cross compiling or native compiling depending on your preference. OE can do all this, Openmoko are just not taking advantage of it. > >---3 "Openmoko should use normal .deb or .rpm packages, instead of > >ipkg/opkg" > >This usually includes people saying we should use src rpms / debian > >src files to build packages. OE can use which ever package format you want. .ipk and .deb both work well. There is rpm code there but it doesn't work, mainly due to limitations in the rpm system. Point me at other build systems where there is package abstraction this good? Using OE gives you the option of changing very easily. > 3.2. I have no experience with building from source packages other than > tarballs. Maybe someone else can comment on that. This comes down to the choice of build system. If you want debian source packages, why not just use debian? OE could create a source package, it could actually consist of a copy of the .bb recipe with the sources. Does that make the distinction clear? > >---4 "Merge the Openmoko distribution into Moblin" Mickey covered this and I know little about Moblin. I also want to add a personal observation about Openmoko. From my perspective there have been a lot of sharp changes in direction, often due to people's personal views on things and I think this lack of dedication to decisions has cost the project badly already. I can believe a number of people don't like OE and want to change. That change will mean massive upheaval and everyone having to learn some new system and probably cost say 6 months 'downtime'. I personally believe this is purely a case of "grass is greener on the other side" and in reality there will always be someone who dislikes the system and there will always be issues with whichever system is chosen. If instead effort is concentrated on fixing the bad things about OE, you can achieve a heck of a lot in 6 months. OpenMoko has not really put that much effort into actually improving the OE infrastructure so far but it does have people who could if they were able to dedicate the time for that and knew what people wanted addressing. I'll also add that Poky is light years ahead with its SDK and IDE environments and there is a quick fix there for some issues ;-). Cheers, Richard
