[oe] Native/Cross/SDK rethink (Was: Re: RFC: "Virtual" native and sdk recipes)

[Esben Haabendal]

On Fri, Jan 2, 2009 at 5:37 AM, Tom Rini <trini at kernel.crashing.org> wrote:
> On Fri, Jan 02, 2009 at 01:11:53AM +0000, Richard Purdie wrote:
>
> [snip]
>> Ideally I want to be able to generate a Linux 32 bit toolchain, a Linux
>> 64 bit toolchain and a windows one. If I can do that using canadian-sdk,
>> the current -sdk stuff can be removed.
>
> It's a theory, and not one I've tested (and I know it won't work _today_
> as there's some hard-coded C:\ paths right now.  Those can die if we
> build it properly relocatible like CodeSourcery does).

Sorry, but where would that be?

In class/canadian-sdk.bbclass:

SDK_PATH_sdk-mingw32 = "/OpenEmbedded/${SDK_NAME}"
SDK_REALPATH = "${SDK_PATH}"
SDK_REALPATH_sdk-mingw32 = "C:/OpenEmbedded/${SDK_NAME}"

Which should only hard-code C:/ into mingw32 toolchains.  I don't
remember seing C:\
in any other places, so that shouldn't get in the way of building
Linux toolchains
with canadian-sdk.

>> Lets for a second make the decision that MACHINE is actually the HOST
>> value. This makes sense in that everything we usually build is to run on
>> the HOST. From here we only need to add gcc-canadian recipe which builds
>> a compiler that runs on HOST but targets a different TARGET to normal to
>> have our BUILD != HOST != TARGET.
>
> Right.  We  get that in the current Canadian stuff, just using different
> variable names, I think.  I _think_ if the new SDK_foo variables were
> set right, it would in fact kick out a working Linux SDK.

I agree on that, although this must come with a YMMV for now ;-)

It would be really great if someone give this a spin, and perhaps a few small
fixes.  I really don't think there should be any big showstoppers ahead.

>> This does reverse the logic that the current sdk class we use however
>> since MACHINE is now the machine we want to run the compiler on, not the
>> machine we want to compile for. It should be simple enough to add some
>> MACHINEs and version setups which correspond to a Linux 32 bit system, a
>> Linux 64 bit system and a windows system though. Assuming the choice of
>> TARGET for gcc-canadian is controlled by a variable like SDKTARGET, to
>> run the builds I'd want, I'd run:
>>
>> MACHINE=i686-generic   SDKTARGET=armv5te-generic bitbake gcc-canadian
>> MACHINE=x86-64-generic SDKTARGET=armv5te-generic bitbake gcc-canadian
>> MACHINE=winxp-generic  SDKTARGET=armv5te-generic bitbake gcc-canadian
>
> Or 'meta-toolchain-sbox' for an existing SDK type target.

I'm sorry, but this seems like a dangerous way of starting confusion of terms.
MACHINE in how I see OE is really the _TARGET_, ie. the small device this all
is targeted at.

And AFAICS, the end result is at best the same as the current canadian-sdk
approach.

>> By contrast, the scheme you are aiming for (as I understand it) would
>> be:
>>
>> MACHINE=armv5te-generic SDKARCH=i686-generic   bitbake gcc-canadian
>> MACHINE=armv5te-generic SDKARCH=x86-64-generic bitbake gcc-canadian
>> MACHINE=armv5te-generic SDKARCH=winxp-generic  bitbake gcc-canadian
>
> With a "but I'm lazy and we'll just re-use current SDK recipes for
> the first choice, canadian for the second and, what? a third choice?
> la-la-la I can't hear you!".  The biggest hiccup I see here is my usage
> would be more like (using current machine.conf's):
> MACHINE=qemux86 SDKTARGET=db1200 bitbake meta-toolchain-sbox

It would be rather nice if local.conf could be setup with the set of SDKARCH's
that is supported by the particular project, so that bitbake canadian-sdk would
actually build sdk's for all required archs.  And a default of
building i686-linux,
x86_64-linux and i686-mingw32 might be a good default setting for this.

>> Also note why I don't see this being possible to combine into one
>> bitbake command, much the same way you can't build 10 machines with one
>> bitbake command.
>
> Trying to get more than one machine into an SDK is something else I've
> pondered, but only lightly so far.

The same thought have hit me as well.
But let's get one thing done right first :-)

Esben Haabendal