[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Patrick Ohly]

On Tue, 2017-05-09 at 13:44 +0200, Patrick Ohly wrote:
> On Tue, 2017-05-09 at 11:00 +0100, Richard Purdie wrote:
> > On Tue, 2017-05-09 at 11:41 +0200, Patrick Ohly wrote:
> > > On Tue, 2017-05-09 at 10:17 +0100, Richard Purdie wrote:
> > > > DISTROOVERRIDES .= "${@bb.utils.contains('DISTRO_FEATURES',
> > > > 'refkit-firewall', ':refkit-firewall', '', d)}"
> > > How does that address the (potential?) cyclic dependency of
> > > "DISTRO_FEATURES depends on OVERRIDES which depends on
> > > DISTRO_FEATURES"?
> > 
> > You either set this feature in overrides or in distro_features and the
> > other is set based on that. You have to choose to make this configured
> > based on one or the other and if you do that it shouldn't cyclical?
> 
> I was wondering more about some other, unrelated distro feature and how
> the code would then expand either OVERRIDES or DISTRO_FEATURES.
> 
> Consider this local.conf example:
> 
>         DISTROOVERRIDES .= "${@bb.utils.contains('DISTRO_FEATURES', 'foo', ':foo', '', d)}"
>         MACHINE = "intel-corei7-64"
>         DISTRO_FEATURES_append_intel-corei7-64 = "bar"
> 
> This could have led to an infinite recursion. In practice, the current
> code already seems to detect the cycle and aborts expanding. But "bar"
> does not get added to DISTRO_FEATURES either:
> 
>         $ bitbake -e  | grep ^DISTRO_FEATURES= | grep -w bar | wc -l
>         0

Duh! "append" semantic strikes again: because of the missing space,
"bar" wasn't found as a separate word by grep. So my test was flawed and
making DISTROOVERIDES depend on DISTRO_FEATURES seems to work in
practice, despite the logical cycle.

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