[OE-core] [PATCH 1/1] image.bbclass: don't expand IMAGE_CMD when setting do_image task

Matt Madison matt at madison.systems
Wed Apr 27 14:19:36 UTC 2016


On Wed, Apr 27, 2016 at 6:03 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2016-04-27 at 05:32 -0700, Matt Madison wrote:
>> Expanding it causes the do_image_x function to include values of
>> variables that may contain date/time stamps, rather than references
>> to the variable names, leading to spurious taskhash mismatch errors.
>>
>> Signed-off-by: Matt Madison <matt at madison.systems>
>> ---
>>  meta/classes/image.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>> index 8bfd241..d695d30 100644
>> --- a/meta/classes/image.bbclass
>> +++ b/meta/classes/image.bbclass
>> @@ -380,7 +380,7 @@ python () {
>>          localdata.delVar('DATETIME')
>>          localdata.delVar('TMPDIR')
>>
>> -        image_cmd = localdata.getVar("IMAGE_CMD", True)
>> +        image_cmd = localdata.getVar("IMAGE_CMD", False)
>>          vardeps.add('IMAGE_CMD_' + realt)
>>          if image_cmd:
>>              cmds.append("\t" + image_cmd)
>
> You can't do this since there are some variables that need to be
> expanded using the values from the current localdata copy of the data
> store (such as the type variable).
>
> We'd previously tried to avoid DATETIME contanination by removing the
> problem bases with the delVar calls just above this.

Rats.  That approach isn't working, at least for me - the recursive
expansion is causing the values of the date/time sensitive variables
to be present in the value of the IMAGE_CMD_type variable, so that
variable changes with each expansion.  I've hacked around the problem
by avoiding direct references to any variable that depends directly or
indirectly on ${DATETIME}, but I was really hoping for something
cleaner.

There are other variables that can cause this, too - ${DATE} and
${TIME} by themselves, for example, which aren't deleted.

Thanks,
-Matt

>
> Cheers,
>
> Richard



More information about the Openembedded-core mailing list