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

[Tom Rini]

On Fri, Jan 09, 2009 at 10:04:35AM -0700, Tom Rini wrote:
> On Fri, Jan 09, 2009 at 12:54:50AM +0000, Richard Purdie wrote:
> [snip]
> > * I'm also not keen on the SDK_PREFIX -> SDK_PATH change. Why? It 
> >   breaks things for people. In fact please back this out before merging 
> >   anything above, I don't see a good reason for it.
> 
> I tried not doing that and got (for MACHINE=efika):
> ERROR: Required build target 'canadian-sdk' has no buildable providers.
> Missing or unbuildable dependency chain was: ['canadian-sdk',
> 'virtual//OpenEmbedded/angstrom/powerpcbinutils']
> 
> That said, all I did was a quick dropping of the change.  I'm going to
> make sure that my current rebasing on top of your current branch builds
> for at least one target then I'll see about dropping the PREFIX->PATH
> change again.  But, I'm unsure if we can, in the current overall SDK
> implementation.  We do need to say "I need
> runs-on-mingw32-builds-for-powerpc binutils".  So the SDK_PREFIX ->
> SDK_PATH (in most cases) change makes sense.  We need one variable for
> the runs-on-builds-for and one for installs-into.  Or is there a trick
> I'm missing (aside from relocatible SDK, which I want)?

OK, I did some more thinking and looking into this.  The problem is that
(as Esben just noted) we have {TARGET,BUILD,HOST}_PREFIX that mean one
thing and SDK_PREFIX that means another.  Adding in the canadian stuff
also means that we need an SDK_PREFIX analogous to the others, along
with the "SDK is compiled for this path" variable.

We can either re-use SDK_PREFIX or in much of the new stuff,
s/${SDK_PREFIX}/${SDK_SYS}-/ but I really think the correct approach is
making SDK_PREFIX mean what {TARGET,BUILD,HOST}_PREFIX mean.  If you
really want, we can hold off on that until the big SDK rework.

-- 
Tom Rini