[oe] Poky SDK generation changes

[Tom Rini]

On Thu, Sep 17, 2009 at 07:59:37PM +0100, Richard Purdie wrote:
> 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.

This all sounds pretty good.  My first concern is where does MACHINE
fit into this stuff?  My second is, is it possible to do something like:
$ SDK_ARCH="i586-linux" MACHINE=machine1 bitbake my-sdk-target
$ SDK_ARCH="i586-mingw" MACHINE=machine1 bitbake my-sdk-target
I assume so.  Then after those two, how about:
$ SDK_ARCH="i586-linux" MACHINE=machine2 bitbake my-sdk-target
$ SDK_ARCH="i586-mingw" MACHINE=machine2 bitbake my-sdk-target

And still get sensible results (assuming my-sdk-target takes MACHINE
into account in naming the output)?

-- 
Tom Rini