Re: Undefining a variable in a recipe?

[Alex J Lennon <ajlennon@dynamicdevices.co.uk>]

On 01/05/2014 18:54, Otavio Salvador wrote:
> On Thu, May 1, 2014 at 2:34 PM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 01/05/2014 14:54, Paul Eggleton wrote:
>>> Hi Alex,
>>>
>>> On Thursday 01 May 2014 10:42:51 Alex J Lennon wrote:
>>>> I have an issue with the build of an old u-boot (2009.08) which is
>>>> failing a check in poky as both UBOOT_CONFIG and UBOOT_MACHINE are being
>>>> defined for some reason.
>>>>
>>>> poky/meta/classes/uboot-config.bbclass
>>>>
>>>>  ubootmachine = d.getVar("UBOOT_MACHINE", True)
>>>>  ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
>>>>
>>>> ..
>>>>
>>>>  if ubootmachine and ubootconfigflags:
>>>>        raise bb.parse.SkipPackage("You cannot use UBOOT_MACHINE and
>>>> UBOOT_CONFIG at the same time.")
>>>>
>>>>
>>>> I have a .bbappend on the original u-boot recipe and could solve the
>>>> problem by undefining UBOOT_MACHINE if I could work out how to do this
>>>> in the .bbappend
>>>>
>>>> I've tried setting it to None or an empty string, and I tried an
>>>> anonymous python function but those approaches didn't help,
>>>>
>>>> e.g. (in the .bbappend
>>>>
>>>> UBOOT_MACHINE = ""
>>> This should work - the python code above is checking if the value evaluates to
>>> True, and that shouldn't be the case for an empty string. I suspect something
>>> else is at work here - either the check is running before your value gets set,
>>> or the value is being set using an override somewhere and therefore your value
>>> isn't being used.
>>>
>>> (adding Otavio on CC since these are his checks and his layer)
>> Thanks for coming back to me on this Paul. OK, I must be
>> misunderstanding something.
>>
>> I was outputting the UBOOT_MACHINE to test and it's not a True value at
>> any point as you
>> might expect as it's set to the machine type if set, but my build was
>> still failing to pick up
>> my preferred recipe version unless I commented out the if/raise, in
>> which case all worked
>> as expected.
>>
>> Caught up with something at the minute but I will go through this  again
>> first thing tomorrow.
> When you debug it let me know and I can try to help in solve it.
>

Much appreciated thanks Otavio. Will do.