[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