Re: building an SDK with an externally provided toolchain

[Denys Dmytriyenko <denis@denix.org>]

On Thu, Apr 29, 2010 at 11:33:33AM -0700, C Michael Sundius wrote:
> Denys,
> 
> in your comment in the thread:
> 
> Re: [oe] [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of
> TARGET_SYS
> 
> > 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.
> >
> I am in a similar predicament where we have to use a tool-chain provided to
> us prior to the adoption of OE. As a result, we've hacked up our own
> external-toolchain recipe to copy the libs and headers into the staging dir,
> but do not have a real cross-compile. we just add the path for the actual
> tools. We also would like to provide an SDK of our libraries separately from
> the toolchain that we deliver to our SDK customers.
> 
> my question is, how do you build your sdk. since our SDK_PATH is not where
> our toolchain is the sdk.bbclass points ${prefix} to /usr/local (which does
> not contain our toolchain) thus much of the makery reverts to looking in
> /usr/include for headers which of course casuse the build to break..
> 
> do you keep your external toolchain from CS in your SDK_PATH or somewhere
> else?
> 
> you seem to allude to the fact that you did some magic to overrite the
> SDKPATH in certain circumstances.. I didn't see it in your code.

The trick is that meta-toolchain recipe does not build any target packages and 
expects them to be already available in deploy - it only opkg-installs them. 
Thus, it's safe to overwrite SDK_PATH when building/assembling the SDK. I have 
a python code in my local.conf (argh, my local.conf already looks like a 
distro.conf) where I set SDK_PATH to point to CSL for normal builds; or set it 
with the directory (provided through a separate variable set on the command 
line) where I want the SDK installed, when building said SDK:

SDK_PATH = "${@[bb.data.getVar('TOOLCHAIN_PATH', d, 1), bb.data.getVar('META_SDK_PATH', d, 1)][bool(bb.data.getVar('META_SDK_PATH', d, 1))]}"

I.e. if META_SDK_PATH is set, assume we are building SDK and set SDK_PATH to 
the root of our SDK, otherwise set it to TOOLCHAIN_PATH, which is CSL. I also 
set TOOLCHAIN_PATH in addition to SDK_PATH in the environment-setup script, 
generated by meta-toolchain.bb

Then I make builds like this:

$ MACHINE=omap3evm bitbake arago-image
$ META_SDK_PATH=/opt/arago-sdk MACHINE=omap3evm bitbake meta-toolchain-arago

Feel free to poke around in the Arago repository:
http://arago-project.org/git/arago.git

-- 
Denys