Re: BBCLASSEXTEND sdk vs. nativesdk

[Richard Purdie <rpurdie@rpsys.net>]

On Wed, 2010-03-24 at 08:57 -0700, Tom Rini wrote:
> On Wed, 2010-03-24 at 15:37 +0000, Richard Purdie wrote:
> > On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote:
> > > 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?

Its no more or less reclocatable than the original was, that wasn't an
objective. Some postprocessing with the same code we use in
packaged-staging shouldn't see it being too bad though.

> How much have we added to the size?

I don't have specific numbers but I did check and it didn't seem
unreasonable on my test builds given that we escaped system dependence.
10MB maybe at a total guess?

If you build against LSB libs, the size shouldn't be any different.

Cheers,

Richard