[oe] BBCLASSEXTEND sdk vs. nativesdk

[Tom Rini]

On Wed, 2010-03-24 at 10:28 +0000, Richard Purdie wrote:
> On Tue, 2010-03-23 at 23:42 -0700, Scott Garman wrote:
> > On 03/23/2010 10:45 PM, Khem Raj wrote:
> > >> It seems to me the correct course of action is to use nativesdk in
> > >> BBCLASSEXTEND and rename the dependencies on other recipes, yes?
> > >
> > > you should rename the dependencies on zlib-sdk to zlib-nativesdk
> > > wherever they exist.
> 
> This isn't quite correct. nativesdk is not a drop in replacement for the
> old sdk but you are right that is is the replacement.
> 
> 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.

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