[OE-core] [PATCH v2 1/1] image-mode.bbclass: common infrastructure for choosing image defaults

Alexander Kanavin alexander.kanavin at linux.intel.com
Wed May 17 12:56:34 UTC 2017


On 05/17/2017 01:47 PM, Patrick Ohly wrote:

> I know that you prefer defining more image recipes over allowing the
> reconfiguration of the same image recipe. I disagree on that, because
> when you have independent aspects (like content and login
> configuration), then you end up with various combinations of those
> configuration options. Writing down all combinations in pre-defined
> image recipes just doesn't scale. But you are welcome to proof me wrong
> by showing how the existing image recipes in OE-core should be changed
> so that they not only cover different content selection, but also what's
> currently done via EXTRA_IMAGE_FEATURES in local.conf.sample.

I disagree that it doesn't scale. It scales just fine with a 
well-constructed include files hierarchy. I'd even argue that's the only 
way to stay sane when there's more than a few product configurations:

all-products.inc
(things common to all products)

product1.inc
(things specific for product1)

product2.inc
(things specific for product2)

production.inc
(where serious security is configured)

development.inc
(where things are made easy for developers)

and then you have

product1-development.bb
====
include product1.inc
include development.inc
====

product2-development.bb
====
include product2.inc
include development.inc
====

product1-production.bb
====
include product1.inc
include production.inc
====

product2-production.bb
====
include product2.inc
include production.inc
====

This pattern is used throughout openembedded. Take a look at machine or 
distro configurations for example, or how both python 2 and 3 can be 
supported with a single recipe include and two very short recipes in 
meta-python. What does IMAGE_MODE do that include files cannot?

Alex




More information about the Openembedded-core mailing list