On Wed, 2017-05-17 at 15:56 +0300, Alexander Kanavin wrote: > 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:
[...] Now add one more mode and you end up with six instead of two image recipes. That's what I consider not scalable. > 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? It does the same thing in a different way. What is preferred is subjective. I think we've both made our opinion clear. Let's hear from others. -- 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. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
