On Fri, Jul 25, 2008 at 1:55 AM, Lauri Leukkunen <[EMAIL PROTECTED]> wrote:
> 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.

That sounds like a pretty good idea and a good place to start. Perhaps
you could laborate on some details I wouldn't mind taking on this
challenge. Especially the setup part and how you think it should work.

>
> 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
> [email protected]
> http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
>
_______________________________________________
Scratchbox-users mailing list
[email protected]
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users

Reply via email to