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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
