From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 93-97-173-237.zone5.bethere.co.uk ([93.97.173.237] helo=tim.rpsys.net) by linuxtogo.org with esmtp (Exim 4.69) (envelope-from ) id 1NuShB-0005wd-2e for openembedded-devel@lists.openembedded.org; Wed, 24 Mar 2010 16:40:37 +0100 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id o2OFbR0X025449 for ; Wed, 24 Mar 2010 15:37:27 GMT Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25068-09 for ; Wed, 24 Mar 2010 15:37:23 +0000 (GMT) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id o2OFbLMv025443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Mar 2010 15:37:21 GMT From: Richard Purdie To: openembedded-devel@lists.openembedded.org In-Reply-To: <1269444453.2395.5.camel@trini-m4400> References: <4B99791E.1020102@zenlinux.com> <4BA981A5.5030609@zenlinux.com> <19c1b8a91003232245y3409bca3p4b74ab5562424b5c@mail.gmail.com> <4BA9B440.2050608@zenlinux.com> <1269426516.1681.35.camel@rex> <1269444453.2395.5.camel@trini-m4400> Date: Wed, 24 Mar 2010 15:37:20 +0000 Message-ID: <1269445040.1681.147.camel@rex> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 X-Virus-Scanned: amavisd-new at rpsys.net X-SA-Exim-Connect-IP: 93.97.173.237 X-SA-Exim-Mail-From: rpurdie@rpsys.net X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on discovery X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, TVD_RCVD_IP autolearn=no version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:20:07 +0000) X-SA-Exim-Scanned: Yes (on linuxtogo.org) Subject: Re: BBCLASSEXTEND sdk vs. nativesdk X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 15:40:38 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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