[Openembedded-architecture] who should set default tunes?

Mark Hatle mark.hatle at windriver.com
Tue May 2 21:46:14 UTC 2017


On 5/2/17 4:37 PM, Phil Blundell wrote:
> On Tue, 2017-05-02 at 16:06 -0500, Mark Hatle wrote:
>> I don't see binary compatibility as a 'DISTRO' thing.  I see it as 
>> a project thing.
> 
> Right, and I think that's the crux of this whole issue.  It seems that
> what you are calling a "project" is what OE has historically called a
> "distribution".
> 
>> If I choose two machines that have some specific set of
>> optimizations, then I'm going to decide the optimization is worth 
>> it, or override that to a common set as part of my local.conf....
>> since only I know what combinations and options I need/want.
> 
> Again, the decisions that you describe yourself taking here are exactly
> the things that a DISTRO maintainer would typically be doing.
> 
> It sounds like the fundamental disconnect really is that you consider a
> build configuration to be a fairly ephemeral thing which might only
> last as long as it takes to build one image and then be thrown away,
> whereas the traditional OE model has been that a DISTRO is a bit more
> of a permanent construct and implies some sort of commitment to long-
> term stability.  

That is -exactly- what I'm expecting.  A project (local.conf) only lasts the
life space on that project and get discarded.  While the distro is re-used over
and over to build more projects.

If I am going to be creating a -binary- feed that is going to have a long-life
and is upgraded over time, then I need to have a project (including local.conf,
PR server, sstate-cache) that will have a long life.  But essentially everything
is still 'disposable' in that a new project can re-use the DISTRO config file
(or choose/create a new one) and do it's minimal configuration in the local.conf.

> I get the impression that what you're really looking for is something
> to give you a grab-bag of configuration policies that you can adopt or
> not as you see fit.  Maybe that's indeed how some DISTROs like to
> operate but I'm not sure it's true for all of them.

The recipes and classes are the grab bag.  A large number of various options..

The DISTRO isn't the grab bag, but the re-usable part of the configuration.
This defines the basic way all of userspace fits together.

The tune (default tune, and multilibs) define how the source is compiled to
product packages -- often by the BSP defined or inherited defaults.

The project (local.conf) then defines the local build rules specific to this
instance of the system.

--Mark



More information about the Openembedded-architecture mailing list