Re: [PATCH] image.bbclass: support TMPDIR/DATETIME inside complex variables

[Patrick Ohly <patrick.ohly@intel.com>]

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.