Re: [RFC][PATCH 0/6] development vs. production builds

[Patrick Ohly <patrick.ohly@intel.com>]

On Tue, 2017-05-16 at 17:02 +0300, Alexander Kanavin wrote:
> On 05/16/2017 04:47 PM, Patrick Ohly wrote:
> 
> > Then why is not already done like that in practice? Is it just because
> > OE-core and Poky set such a bad precedence with teaching developers to
> > add EXTRA_IMAGE_FEATURES ?= "debug-tweaks" to make the images usable,
> > and then that approach gets copied?
> 
> It is done like that already, it's just not very consistent from what I 
> can see. For example, core-image-sato-dev.bb:
> =============
> require core-image-sato.bb
> 
> DESCRIPTION = "Image with Sato for development work. It includes 
> everything \
> within core-image-sato plus a native toolchain, application development 
> and \
> testing libraries, profiling and debug symbols."
> 
> IMAGE_FEATURES += "dev-pkgs"
> =============

That's different. Here an image recipe specifies what it is meant to
*contain*, not how it is meant to *behave*.

One would need core-image-sato-dev-production.bb (no debug-tweaks,
dev-pkgs), core-image-sato-dev-debug.bb (debug-tweaks, dev-pkgs),
core-image-sato-production.bb (no debug-tweaks, no dev-pkgs),
core-image-sato-debug.bb (debug-tweaks, no dev-pkgs).

Allowing EXTRA_IMAGE_FEATURES in local.conf.sample avoids that.

> I'm not a big fan of placing INHERIT into local.conf either, by the way. 
> I believe in functional programming principles, and this goes directly 
> against them.

It makes sense to me when the functionality is orthogonal to the
content, like enabling buildhistory.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.