[oe] [RFC] Stop on multiple providers but none explicitly specified

Leon Woestenberg leon.woestenberg at gmail.com
Thu May 15 20:50:58 UTC 2008


Hello Tom,

On Thu, May 15, 2008 at 10:11 PM, Tom Rini <trini at kernel.crashing.org> wrote:
> On Thu, May 15, 2008 at 08:51:29PM +0200, Leon Woestenberg wrote:
>
>> However, is it intuitive from the *user's* point-of-view to have
>> BitBake make this decision?
>> I think not; at least in the case of OpenEmbedded, there is at least a
>> 50% chance this is not what the user intended.
>>
>> 1) Besides fixing this in BitBake (by bailing out, my first proposal),
>> 2) an alternative solution is to set the preferred provider for the
>> toolchain/libc elements to a built..
>> a) ..in each distro file
>> b) ..globally where we can build the toolchain/libc elements in
>> OpenEmbedded for the target.
>>
>> I think 2a)  is not the way OpenEmbedded should work. The distro is
>> not the authorative component that decides whether we can build a
>> toolchain/libc for each target (like Angstrom does now).
>>
>> Shouldn't we do (2b), where the distribution can *optionally* override
>> the preferred provider if it knows better?
>
> How do we know what's right?  Since in many cases it's glibc OR uclibc
> OR external-toolchain, there is no right default there.  If we just bail
> out here..
>
Yes, bailing out is my first proposal, which modifies bitbake.

"Setting what's right" is a secondary solution, and modifies
OpenEmbedded metadata. I would prefer to default to our self-built
toolchain for targets that have a known "good" cross-toolchain in
OpenEmbedded. We can default to glibc for targets where glibc is the
"best" choice, i.e. bigger targets, and default to uclibc where it
makes sense (your favourite router?).

The distro can override where necessary (this is the exception, and in
most cases it locks down toolchain versions, does not select
providers).

> - Distro maintainers know what's right for their distro and lock things
>  down (or know the complex table of their correct answers, and lock
>  down).
>
Hmm, do I *need* to set a distro?

Does the *distro* limit me to what targets I want to build?

What if I want to build helloworld-image for the microblaze
achitecture? (Just babbling here - but it has MMU now :-).

> - End users never see this unless the distro isn't up to date, and ping
>  the distro maintainer.
>
No. Only very experienced end users ping the distro maintainer. New
end-users complain on #oe, they don't see the NOTE: at the top, and
don't understand why stuff fails.

> - Custom folks get a build that bails out, with a good reason and they
>  pick what they know they need here.
>
Yes, my preference.


But let me put it another way:

The concept of distro's should not restrict me from using OpenEmbedded
as a cross platform build system. Our default configuration should
much mimick buildroot. Select machine, packages, go. We should start
where buildroot ends.

Use cases:

Selecting "MACHINE=microblaze_dev_board, bitbake helloworld-image.bb"
should work out of the box if we add the microblaze toolchain.

Selecting "MACHINE=new_machine_with_new_arch DISTRO=old_distro bitbake
some-image.bb" should as least TRY to build the image for the machine
using the toolchain that is available in OpenEmbedded.

My 2cts,

Regards,
-- 
Leon




More information about the Openembedded-devel mailing list