[OE-core] [RFC][PATCH 0/6] development vs. production builds

[Alexander Kanavin]

On 05/16/2017 05:25 PM, Patrick Ohly wrote:
>>
>> 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*.

You can totally specify behavioral IMAGE_FEATURES in image recipes. The 
distinction is not formally specified or enforced anywhere, as far as I 
know.

> 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.

Consider that the suffix in image recipe name is essentially same as 
your IMAGE_MODE idea. It specifies who is the target audience for the 
image. Then you can avoid combinatorial explosion, if you define who the 
image is meant for:

someimage-developers.bb (debug tweaks, dev-pkgs)
someimage-endusers.bb (no debug tweaks, no dev-pkgs)

>> 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.

Unfortunately, there is no way to enforce orthogonality. The door is 
wide open for awful hacks here.

Alex