[OE-core] [RFC][PATCH 0/6] development vs. production builds
Patrick Ohly
patrick.ohly at intel.com
Tue May 16 14:25:34 UTC 2017
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.
More information about the Openembedded-core
mailing list