On 24/07/08 10:33 -0500, E Robertson wrote: > So is there any strategy to resume the fun? One of the biggest problem > with SB2 as I see it is lack of documentation that really describes > it (especially the differences) wrt SB1. I wouldn't mind helping in > this area if I understood more of it. Unfortunately, It was only until > I took a look at OE that I realize what SB2 was trying to do, less the > toolchain ( by the way, the last time I checked CodeSourcery toolchain > didn't support uClibc). What little documentation is has is focused > on Maemo and I've never used this SDK because from what I've seen it's > too bulky. Maybe soon I'll be motivated to take another stab at SB2.
Maybe we should put together an openembedded SDK using SB2, then we would have two big sample SDKs demonstrating two different roles SB2 can play. Maemo SDK+ would demonstrate the heavy weight use with fully controlled build tools, debian packaging and all of the cross-compilation problem solving being done by SB2. OEwSB2 would be built so that OE's own build system is used to provide the binary rootfs and then SB2 would be used for compiling individual applications or libraries on top of it, using the OE provided toolchain. This would be akin to the SDK provided by Apple for iPhone etc, basically useful for developing applications for a device that has a released software with APIs that are not expected to be broken. For developing the core OE part, one would probably prefer to do it in OE's own build framework, but for the apps SB2 could provide a useful way to allow cross-compiling without having to integrate the app to OE itself. The same could be done for debian-armel too. Maybe trying to replace the native builds with SB2 for them is not realistic(?), but producing a nice way of developing software directly for it wouldn't hurt. /lauri _______________________________________________ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
