Re: Poky SDK as an external toolchain

[Mark Hatle <mark.hatle@windriver.com>]

On 10/14/11 11:15 AM, Richard Purdie wrote:
> On Fri, 2011-10-14 at 11:06 -0500, Mark Hatle wrote:
>> On 10/14/11 9:44 AM, Gary Thomas wrote:
>>> Premise: I'm happy with the toolchain that builds with Poky/Yocto
>>> Problem: I'm not happy rebuilding said toolchain all the time, nor
>>> having my customers have to rebuild it.
>>>
>>> Solution? I'd like to build the meta-toolchain and then be able to
>>> use that as an external toolchain for subsequent builds.  That way,
>>> I can create the tools and reuse them internally as well as pass
>>> them to my customers.
>>>
>>> How can I make this happen?  The last time I tried anything like
>>> this, I spent many days in the attempt only to find out that it
>>> was never going to work...
>>
>> We have a similar need for our commercial products.  We allow/enable our
>> customers to rebuild the toolchains (and use the results), but we only provide
>> official support for our binary versions.  There are simply too many variations
>> possible to try to support the toolchains in source format.  (Toolchains =
>> bintuils, gcc, stock eglibc and a stock uclibc configurations...)
>>
>> Our intention is simply to create custom recipes that extract our binaries and
>> use them instead of doing a by-source build.  If there is an easier way that
>> would be nice.  (And I agree, using the results of the meta-toolchain build is
>> the right approach for anything standard.)
>>
>> I'd suggest this get added as an enhancement request to the bugzilla.  We're
>> currently working on feature planning for 1.2 so this would be a good time to
>> add it into the bucket of possible work items.
> 
> We already support external toolchains just fine. You can use a
> meta-toolchain as an external toolchain.

But we don't have a way to use OUR external toolchain directly as the toolchain
for building, avoiding building new ones right?

> If you want to reuse the toolchain directly, we do have sstate and we
> need to fix issues it has. We know and acknowledge they exist, we just
> need to track down the problems and fix them. The more people who help
> with that the sooner it will get done.

This is one case where I think sstate is only the answer for those folks who
want to speed rebuilding.  But in the case where you've come up with a certified
set of binary components.. there needs to be a way to inject that in without the
weight of the sstate.  (Copy of all of the various stages of the install, build,
packaging..)

> If anything goes into the bugzilla it should be examples of where sstate
> is failing. Most sstate bugs do get resolved failrly quickly.

I think this is a different usecase then the sstate.  To me sstate allows the
use of a cache to speed up building.  This is a case where we want to use
something external (which happens to be built by the build system -- setting the
default format) to avoid performing any build operations.

--Mark

> Cheers,
> 
> Richard
>