[OE-core] [PATCH v2 1/2] bitbake.conf: DISTRO_FEATURES as overrides

Patrick Ohly patrick.ohly at intel.com
Wed Jun 14 10:32:02 UTC 2017


On Tue, 2017-06-13 at 09:14 +0200, Patrick Ohly wrote:
> On Mon, 2017-06-12 at 19:23 -0400, Denys Dmytriyenko wrote:
> > On Mon, Jun 12, 2017 at 11:05:19PM +0200, Patrick Ohly wrote:
> > > On Mon, 2017-06-12 at 15:46 -0400, Denys Dmytriyenko wrote:
> > > > This now breaks parsing my distro config on these lines:
> > > > 
> > > > ENABLE_SYSVINIT ?= "0"
> > > > DISTRO_FEATURES_append = "${@base_conditional("ENABLE_SYSVINIT", "1", "", " systemd", d)}"
> > > > 
> > > > 
> > > > Here's the log:
> > > > 
> > > > ERROR: Unable to parse /OE/arago-master/sources/bitbake/lib/bb/data_smart.py
> > > > Traceback (most recent call last):
> > > >   File "/OE/arago-master/sources/bitbake/lib/bb/data_smart.py", line 426, in DataSmart.expandWithRefs(s='${@base_conditional("ENABLE_SYSVINIT", "1", "", " systemd", d)}', varname='DISTRO_FEATURES_append'):
> > > >                  except Exception as exc:
> > > >     >                raise ExpansionError(varname, s, exc) from exc
> > > >      
> > > > bb.data_smart.ExpansionError: Failure expanding variable DISTRO_FEATURES_append, expression was ${@base_conditional("ENABLE_SYSVINIT", "1", "", " systemd", d)} which triggered exception NameError: name 'base_conditional' is not defined
> > > 
> > > base_conditional() seems to come from utils.bbclass, which gets
> > > inherited by base.bbclass. Looks like DISTRO_FEATURES and thus this
> > > DISTRO_FEATURES_append end up getting expanded before these classes are
> > > fully parsed.
> > 
> > FWIW, replacing it with oe.utils.conditional() doesn't help.
> 
> How about the following patch? It solves the problem for me.

Richard had concerns about rewriting OVERRIDES in an event handler,
therefore we agreed to use the .bbclass approach that I originally
started with. I'm still testing that in refkit (blocked by trying to
move towards bleeding edge OE-core master-next, on which my patch was
based), but it should be ready at least for OE-core master-next, so I'll
post it now.

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