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

[Denys Dmytriyenko]

On Sat, Apr 24, 2010 at 11:51:09AM -0700, Tom Rini wrote:
> On Sat, 2010-04-24 at 13:07 -0400, Denys Dmytriyenko wrote:
> > On Fri, Apr 23, 2010 at 02:43:13PM -0700, Tom Rini wrote:
> > > On Fri, 2010-04-23 at 16:54 -0400, Denys Dmytriyenko wrote:
> > > > On Fri, Apr 23, 2010 at 10:29:54PM +0200, Koen Kooi wrote:
> > > > > >> 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 know it's not what you are looking for, but easier workaround would be to 
> > > > install different toolchains in different paths... :)
> > > 
> > > Or, noting all of the very machine specific stuff Koen mentions
> > > elsewhere, we don't pretend it's an SDK for armv7a but just call it an
> > > SDK for ${MACHINE} and encode that into the PATH.
> > 
> > The thing is, while SDKPATH is the same by default for both of the 
> > incompatile toolchains (e.g. for Angstrom it is /usr/local/angstrom), the 
> > resulting tarballs are named with the specific architecture in the name taken 
> > from the FEED_ARCH:
> > 
> > TOOLCHAIN_OUTPUTNAME ?= "${DISTRO}-${DISTRO_VERSION}-${SDK_SYS}-${FEED_ARCH}-${TARGET_OS}-${SDK_SUFFIX}"
> > 
> > While not machine-specific, when installed in separate locations, can safely 
> > separate armv5te from armv7a. That way even the host cross tools are separated.
> 
> Right.  I'm saying that SDKPATH should be more than /usr/local/${DISTRO}
> but /usr/local/${DISTRO}/${MACHINE} by default, toss a comment above
> about why (output is very MACHINE specific in certain cases) and maybe
> update the default TOOLCHAIN_OUTPUTNAME too.

Ok, you asked for a comment, I'll give you two :)

1. In Arago I have a way to overwrite SDKPATH from the command line when 
building a specific SDK/toolchain. So, I can do what you suggest, but...

2. My SDKs are currently not machine-specific, moreover, they don't have the 
cross-compile tools in them (i.e. no toolchain part), as Arago uses external 
CodeSourcery toolchain for that. The only cross-tools I have in my SDKs are 
those, which are missing from CS - i.e. libtool, pkgconfig, opkg, qt4e-tools 
etc. But I still build 2 versions of SDK - armv5te and armv7a.

-- 
Denys