[oe] BBCLASSEXTEND sdk vs. nativesdk

[Tom Rini]

On Wed, 2010-03-24 at 15:37 +0000, Richard Purdie wrote:
> 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)? :)

How is this working on the runtime?  How relocatable is it?  How much
have we added to the size?

-- 
Tom Rini <tom_rini at mentor.com>
Mentor Graphics Corporation