building an SDK with an externally provided toolchain

building an SDK with an externally provided toolchain

[C Michael Sundius]

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.
>
> --
> Denys
>
>
> 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.

Thanks for your help.

Mike

Re: building an SDK with an externally provided toolchain

[Denys Dmytriyenko]

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