[oe] [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-04-10 20:55, Tom Rini wrote:
> On Fri, 2010-04-23 at 20:45 +0200, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 23-04-10 20:22, Denys Dmytriyenko wrote:
>>> On Fri, Apr 23, 2010 at 11:07:33AM -0700, Tom Rini wrote:
>>>> On Fri, 2010-04-23 at 13:07 +0200, Koen Kooi wrote:
>>> Ping
>>>>>
>>>>> It's better than what we have today, true.  And SDKPATH already contains
>>>>> DISTRO, which is the likely changer of TOOLCHAIN_*_TASK.  So...
>>>>>
>>>>> Acked-by: Tom Rini <tom_rini at mentor.com>
>>>
>>>> In general:
>>>
>>>> Acked-by: Denys Dmytriyenko <denis at denix.org>
>>>
>>>> But, should we then create an arch-specific environment-setup scripts (e.g. 
>>>> one for armv4 and another for armv7a, as per your example below)?
>>
>> Yes, that needs to be done, as well as seperating the cross tools in
>> case different archs need different versions (as is the case with
>> angstrom, v5te and v7a need different binutils). This change largely to
>> to cosmetically highlight that the toolchain is not really "universal"
>> (yet).
> 
> And we can talk about if "universal" is really a good goal either.

I don't think we can make it "universal" without sacrificing key benefits.

> Taking a bit of a guess in the dark, an SDK with support for all the fun
> stuff found on Beagleboard might not be done easily with also having
> support for all the fun stuff found on some other ref board too.

The immediate problem I'm trying to address now is that having both an
armv5te and armv7a toolchain installed is breaking horribly. Ideally
they would coexist peacefully, but I don't know if we can manage that,
without impacting the ease of use.

> I tend to think of these exports as being very board specific, but that
> doesn't quite flow with how others think of this stuff, today.

The current output is highly machine specific, since it will include
MACHINE_ARCH in the opkg configuration. For gcc/libc/binutils that is
usually OK (except when using an ep93xx sdk to target e.g. om-gta01),
but for things like clutter or mesa where the machine directly impacts
the shared lib it gets ugly real fast.
Luckily at work I currently have a fairly nice situation: all arm9
targets are arm926 without any form of VFP/FPA and no 3d accell and all
cortex-a8 targets have the same VFP and NEON blocks and the 3D accel is
the same. Of course with my angstrom hat on, the situation is different...

I'm eagerly awaiting Richards branch to get merged so I can work on the
nicer areas of meta-toolchain-qte :)

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL0gNCMkyGM64RGpERAiVuAJ4jIidQWTLhphBZl1sK5gxdZ6gM1gCguxNG
kEfwpxZtU3TJg6cC/XCSSeI=
=HXKJ
-----END PGP SIGNATURE-----