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 <[email protected]> Mentor Graphics Corporation _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
