[OE-core] [PATCH] image.bbclass: support TMPDIR/DATETIME inside complex variables
Patrick Ohly
patrick.ohly at intel.com
Fri Jan 22 07:29:26 UTC 2016
On Thu, 2016-01-21 at 14:23 +0100, Patrick Ohly wrote:
> Not replacing TMPDIR at all (from in OE-core:a8c377beadb85b0ff50)
> led to an expansion error when INITRD needs to passed to the image command:
> ERROR: ExpansionError during parsing ....bb: Failure expanding variable INITRD, expression was ${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', '${TMPDIR}/deploy/images/intel-corei7-64/microcode.cpio ', '', d)}
>
> That's because the replacement of ${@ stops at the curly brackets after
> TMPDIR, leading to an incomplete Python expression. The right solution
> would be to enhance bitbake's data_smart.py such that it does not rely
> on a regular expression to find the matching closing bracket.
Richard proposed a different solution for this, which is an enhancement
for bitbake which stops expanding Python expressions when the problem
strikes:
http://lists.openembedded.org/pipermail/bitbake-devel/2016-January/006932.html
I'm fine with dropping my proposed patch and using the bitbake
enhancement instead. I checked that it also addresses the specific
problem that I ran into.
However, after thinking about it some more, I suspect that it leads to
situations where sstate hashes do not properly track variable
dependencies.
Suppose an image command is passed a variable like this:
FOO = "${@ os.join.paths('${TMPDIR}', (bb.utils.contains('BAR', 'a', 'x', 'y', d)}"
If the entire expression was expanded, the result would change depending
on whether BAR contains a or not. But because expanding the Python
expression stops, FOO is essentially constant when checking sstate
hashes and only expands later.
So ultimately, a proper solution for matching brackets for Python
expressions in data_smart.py will be needed to cover all cases.
--
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