Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Using meta-toolchain output as prebuilt toolchains
Date: Tue, 29 Mar 2011 05:32:43 -0600	[thread overview]
Message-ID: <4D91C35B.50708@mlbassoc.com> (raw)
In-Reply-To: <4D90DA4A.3030605@mentor.com>

On 03/28/2011 12:58 PM, Tom Rini wrote:
> On 03/27/2011 04:44 AM, Koen Kooi wrote:
>> Hi,
>>
>> What is the preferred way of 'importing' prebuilt toolchains into OE-core? In oe.dev I can use this: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/meta/external-toolchain-angstrom.bb to 'import' an angstrom toolchain built with 'bitbake meta-toolchain', but I'm not sure how to do that in OE-core.
>>
>> My actual use case is actually 2 use-cases:
>>
>> 1) Hand people a prebuilt angstrom toolchain and migrate them to OE while keeping the toolchain
>> 2) "Get started in 10 minutes" type of thing, I suspect an sstate mirror might be better.
>>
>> So any suggestions for #2 as well?
>
> sstate is the best way to catch #2 and I know in general there's "look
> at this URI for the file you want" bits.  I haven't yet started kicking
> the tires on sstate as hard as I have for packaged-staging however.

This is the approach I've been working on to pass on to my customers.  The
idea that I can give them a packaged bundle which includes prebuilt tools
is far more attractive than a simple poky (or oe-core plus layers) tree
which involves many hours of building to produce a simple image.

Hopefully, the sstate method will become more stable over time.  The problem
I've had with it recently is that there are so many variables which are used
to decide if the sstate data is valid (see Richard's description on how this
works) that if the smallest thing changes, the whole lot becomes useless :-(
so it's really only valid for a [fairly] static repository.

>
> For #1, I believe external toolchains are to be supported still, but I
> don't know off hand if the recipes still work (but there is both an old
> CSL one as well as a poky toolchain one in meta/recipes-core/meta/).
> Another area on my TODO list...
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



  reply	other threads:[~2011-03-29 11:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-27 11:44 Using meta-toolchain output as prebuilt toolchains Koen Kooi
2011-03-27 19:34 ` Khem Raj
2011-03-27 20:26   ` Koen Kooi
2011-03-28 18:58 ` Tom Rini
2011-03-29 11:32   ` Gary Thomas [this message]
2011-03-29 15:32     ` Richard Purdie
2011-03-28 19:25 ` Richard Purdie
2011-03-31 19:36   ` Denys Dmytriyenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D91C35B.50708@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox