Re: Usage of meta recipe external-toolchain-csl

[Denys Dmytriyenko <denis@denix.org>]

On Fri, Apr 30, 2010 at 09:01:22PM +0200, Jerry Jacobs wrote:
> On Fri, Apr 30, 2010 at 7:58 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> >
> > On Fri, Apr 30, 2010 at 09:53:06AM -0700, Tom Rini wrote:
> > > On Fri, 2010-04-30 at 15:34 +0200, Jerry Jacobs wrote:
> > > > Dear all,
> > > >
> > > > I'm very new to openembedded and already have a clear view how it is
> > > > structured. My embedded board mini2440 is already in git and want to create
> > > > my own distro.
> > > > The problem where I bump against is how to use the Codesourcery external
> > > > toolchain for my target. I know there is the file in recipes/meta/
> > > > external-toolchain-csl.bb
> > > > but it not clear how to use it.
> > >
> > > There's 2 ways.  One way is, in local.conf:
> > > ### CSL public ARM does <arch>-none-<os>, so fill in the -none
> > > TARGET_VENDOR = "-none"
> > > ### Bring in external-toolchain-csl.bb
> > > TOOLCHAIN_BRAND = "csl"
> > > ### Where the CSL version is installed.
> > > TOOLCHAIN_PATH = "/full/path/to/arm-2009q3"
> > > ### Where inside the CSL install the target libraries exist.
> > > TOOLCHAIN_SYSPATH = "${TOOLCHAIN_PATH}/arm-none-linux-gnueabi"
> > > ### Add tools to the PATH automatically.
> > > PATH_prepend = "${TOOLCHAIN_PATH}/bin:"
> > > require conf/distro/include/toolchain-external.inc
> > >
> > > The other way has a few less variables in local.conf but assumes PATH is
> > > already updated.  Denys will reply shortly with that, I imagine.
> >
> > The only difference I have from Tom's setup is I expect the CSL toolchain
> > being already in the PATH variable:
> >
> > export PATH=/full/path/to/arm-2009q1/bin:$PATH
> >
> > And then set the other several BitBake variables accordingly (in local.conf
> > and toolchain-csl.conf):
> >
> > TARGET_VENDOR = "-none"
> > # no need to include/require toolchain-external.inc, as TOOLCHAIN_TYPE does it
> > TOOLCHAIN_TYPE = "external"
> > TOOLCHAIN_BRAND = "csl"
> >
> > [There I also set CPPFLAGS and LDFLAGS to point to CSL directly, but it's not
> > required as necessary files are staged by the recipe these days.]
> >
> > The "black magic" in the local.conf is basically a Python code to set
> > TOOLCHAIN_PATH and TOOLCHAIN_SYSPATH based on the user's PATH:
> >
> > TOOLCHAIN_PATH = "${@code-to-extract-csl-path-from-PATH}"
> > TOOLCHAIN_SYSPATH = ${TOOLCHAIN_PATH}/${TARGET_SYS}
> >
> > So, with my setup, no modifications to local.conf are required, as long as CSL
> > is in your PATH. With Tom's setup, users would need to add the CSL path to
> > local.conf.
> >
> > Hope this helps.
> >
> > --
> > Denys
> 
> This clears things up, bit still its not sufficient to get it working.
> 
> The DISTRO seems to overwrite the TOOLCHAIN rules. And this while I
> set the TOOLCHAIN variables in local.conf

Can you please be more specific? Grepping conf/ shows all the assignments 
of TOOLCHAIN_* vars are weak.

> And why compiles it things like coreutils-native? This are the tools
> needed to compile software, like make, autoconf?
> NOTE: package coreutils-native-7.2-r1: task do_setscene: Started

coreutils-native provides basic commands like cp, mv, cat, ls, mkdir, mknod, 
install etc. That ensures we have sane versions of those with the expected set 
of supported command line parameters... If you know your host OS/distro 
provides the same, feel free to add coreutils-native to ASSUME_PROVIDED in 
your local.conf...

-- 
Denys