[oe] RFC: "Virtual" native and sdk recipes

[Tom Rini]

On Thu, Jan 01, 2009 at 08:11:27PM +0000, Richard Purdie wrote:
> 
> On Thu, 2009-01-01 at 11:25 -0700, Tom Rini wrote:
> > On Thu, Jan 01, 2009 at 04:25:14PM +0000, Richard Purdie wrote:
> > 
> > > Its nice to try something a bit different occasionally. For a long time
> > > the mechanical repetitive nature of -native and -sdk recipes has
> > > bothered me and people have talked about getting rid of them since
> > > forever. I've had ideas floating around on how to address this for a
> > > while and I now have a proper proposal and better still a proof of
> > > concept.
> > 
> > I'll read the whole thing again later, but in working on the canadian
> > SDK stuff (*poke*) I've been thinking why don't we just build the "SDK"
> > packages for building our own stuff?  gcc/etc are relocatible if we
> > build them right...
> 
> Even if gcc is relocatable, some software (quilt springs to mind) has to
> be built using the paths it will be installed to. I'll happily support
> any effort to make as much as possible support relocation but at the
> very least we'll continue having -native packages and its them this is
> primarily aimed at. I wouldn't want to miss the opportunity to kill off
> many of the -sdk packages in poky at the same time though!

I know for quilt specifically anything you can compile in as a path you
can override in quiltrc, and you can pass-in --quiltrc, so... next? :)
But yes, I too wouldn't mind having a few less -sdk packages in my own
stuff too.

> I've been wondering how much the canadian SDK code will benefit from
> this and perhaps you can give some input on that?

Off the top of my head, it depends on if we want to allow one env to
make both a Linux and a Windows SDK.  The foo-canadian-sdk packages can
fit very easily into any reuse scheme (the gcc ones look like all of the
others now).  I was thinking there's no reason really (esp if we build
gcc correctly for relcation, which we don't now) that any 'target gcc
for sdk' recipe couldn't build for any one Linux or Windows target, but
not both.  For my needs, I want both Linux and Windows SDKs kicked out
from one bitbake invokation.

-- 
Tom Rini