Re: BBCLASSEXTEND sdk vs. nativesdk

[Richard Purdie <rpurdie@rpsys.net>]

On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote:
> On Wed, 2010-03-24 at 10:28 +0000, Richard Purdie wrote: 
> > The difference is that the old "sdk" assumes the system you want the sdk
> > to run on is the same as the build system. This has always been a big
> > can of worms causing problems so "nativesdk" removes this assumption and
> > allows you to set SDKMACHINE to be the machine you want the resulting
> > sdk to run on.
> > 
> > This adds some complexity since we need another cross compiling
> > toolchain. But cross compiling toolchains are something we're good
> > at :). It also means we ship *everything* with the sdk including a
> > standalone glibc massively removing system dependencies from the result
> > which in my opinion can only be a good thing.
> 
> Or a really bad thing, yes.  I think nativesdk will help out a lot for
> making canadian style builds cleaner.  But going so far as to say 'Oh,
> lets just throw a libc into the SDK export' is going pretty far down a
> questionable road.  I'm not so naive to think that there's not problems
> with my next suggestion, but there's this thing called LSB for a reason.
> If you want build once, run many distributions, you do that, not go and
> own even more dependencies.

However, an LSB compliant SDK becomes a case of installing "LSB" libs
into the right sysroot and then setting some
ASSUME_PROVIDED/PREFERRED_PROVIDER lines.

So I think its good all around, we achieve independence of the SDK from
the build system and make it depend on exactly what we do or don't want
it to. Where is the bad bit (ignoring build time)? :)

Cheers,

Richard