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