Poky SDK generation changes

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

Re: 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

Re: Poky SDK generation changes

[Richard Purdie]

On Thu, 2009-09-24 at 12:49 -0700, Tom Rini wrote:
> This all sounds pretty good.  My first concern is where does MACHINE
> fit into this stuff?

MACHINE changes the target of the SDK so it is taken into account.

>   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

Yes, this all does exactly what you'd expect. 

I've also added "SDKMACHINE" to Poky too which works like MACHINE with
some predefined .conf files for common targets.

Cheers,

Richard