[oe] Poky SDK generation changes

[Richard Purdie]

As people who've used it probably know, SDK generation is a bit of a
hack at the moment since the SDK is compiled against the system its
built on. This means its not possible to produce a i586 SDK on a x86_64
build machine for example.

The current sdk.bbclass also has an identity crisis powering both cross
toolchain recipes (like gcc, binutils and gdb) along with non-cross sdk
tools like qemu and pkgconfig.

I've wanted to see "proper" SDK generation with Poky for a while and
I've now created a series of patches which enable this which includes
the layout variable changes I previously mentioned:

http://git.pokylinux.org/cgit.cgi/poky/log/?h=canadian

The idea is similar to some of the canadian* classes in OE.dev but I
ended up rewriting them entirely as I believed something simpler was
possible and desirable. The idea is the same in that you set
SDK_ARCH="i586" in local.conf and then the SDK will be one that runs on
that ARCH.

The end result is three classes:

cross-canadian.bbclass
crosssdk.bbclass
nativesdk.bbclass

nativesdk - These recipes provide "SDK" versions of the recipe for
things like pkgconfig, qemu, the xlibs qemu needs and so on. The class
is BBCLASSEXTEND capable so its usually just a case of adding
BBCLASSEXTEND = "nativesdk" to the recipe.

crosssdk - These build a cross compiler toolchain which runs on your
build machine and cross compiles to SDK_ARCH. Its pretty much
cross.bbclass but with TARGET_ARCH = SDK_ARCH.

canadian-cross - These are the strangest packages as they're built on
BUILD_ARCH to run on SDK_ARCH to generate output to run on TARGET_ARCH.

As a nice benefit we end up with a libc in the SDK tarball which the SDK
uses instead of linking against the one on the build machine. Poky also
contains some code to link qemu against a dummy libGL as I didn't
believe adding a libGL to the SDK tarball was sensible.

I've cc'd the OE list since I think the changes in here are desirable
for OE too. I haven't had much time to run OE builds of late for many
reasons. I don't really want to make changes there without testing the
result so any help in merging this into OE would be really appreciated.

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre