Re: Undefining a variable in a recipe?

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

[-- Attachment #1: Type: text/plain, Size: 4065 bytes --]


On 02/05/2014 14:23, Otavio Salvador wrote:
> On Fri, May 2, 2014 at 10:11 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 02/05/2014 14:07, Otavio Salvador wrote:
>>> On Fri, May 2, 2014 at 10:01 AM, Alex J Lennon
>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>> On 02/05/2014 13:56, Otavio Salvador wrote:
>>>>> On Fri, May 2, 2014 at 2:24 AM, Alex J Lennon
>>>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>>> ...
>>>>>> So I guess I'm at the point where I'm wondering if a getVar() with a
>>>>>> flag is behaving as you would expect it to,
>>>>>> or how I might go about ensuring either UBOOT_MACHINE or UBOOT_CONFIG
>>>>>> isn't defined?
>>>>>>
>>>>>> Thanks in advance for any advice,
>>>>> I think we have a simple error error. You are mixing a recipe, which
>>>>> is old and a metadata layer with new concepts.
>>>>>
>>>>> The u-boot-imx, in 2009.08 recipe, used to set the UBOOT_MACHINE in
>>>>> the recipe as it was left as a fallback in case user needed it and the
>>>>> value was different from newer releases.
>>>>>
>>>>> In your case, the easier is to make a new yourmachine.conf and use the
>>>>> UBOOT_CONFIG or UBOOT_MACHINE setting there so it will work just fine.
>>>>>
>>>> If I have to do that, then I have to do that.
>>>>
>>>> However if I could just undefine one of the two variables defined in the
>>>> meta-fsl-arm
>>>> layer then I could continue with what I am doing without having to spend
>>>> the time
>>>> right now to rework the configuration, which is wasted effort for me, as
>>>> I will be moving
>>>> up to the new version of u-boot in the near future.
>>>>
>>>> Is there no simple way to undefine a variable in a recipe?
>>> You can change the recipe byhand. This is ugly and I wouldn't do it. I
>>> do think you are wasting more time trying to 'workaround' it than
>>> fixing it.
>> Or indeed, would be not be reasonable to modify the uboot-config.bbclass
>> such that
>> it tested for and discarded empty strings in UBOOT_MACHINE / UBOOT_CONFIG
>> which would seem to be a more complete test and would eliminate the
>> problem ?
> Like: http://privatepaste.com/8046479967
>
>>> Comment the UBOOT_MACHINE setting in the u-boot-imx recipe and move
>>> on. The log is clear you're not setting the PREFERRED_VERSION
>>> accordingly and you should.
>>>
>> You've lost me. Why am I not setting PREFERRED_VERSION accordingly? I have
>> two recipes in the checkout and I have configured prefer the older one,
>> which
>> seems entirely reasonable.
> Your log say's it looks for u-boot-imx 2013.04 and not for 2009.08.
>

I might be misunderstanding what you are saying here, but if you look at
my earlier email, and check the patchbin snippets I provided you will
see I am preferring 2009.08

 1.
    PREFERRED_VERSION_u-boot-imx="2009.08"

The test in uboot-config.bbclass causes this to fail/be unavailable to
the build, which is why the log says I cannot use 2009.08, instead
falling back to the newer version. Removing the two lines checking for
the definition of the two variables results in the 2009.08 build
completing successfully - but I don't want to leave that little bomb in
meta-fsl-arm for colleagues to fall over in future.

I cannot override what meta-fsl-arm is setting because I can't (or don't
know how to) undefine one of those two variables in my bbappend, and
although I believe I _can_ set it to an empty string as  Paul suggested,
I don't believe the the getVar() code in uboot-config.bbclass checks
this, although I'm a bit unclear on the semantics of that function call.

I appreciate the help here Otavio, and I was hoping there was a simple
non-invasive way to solve the problem by undefining the variable in my
layer, as it seemed cleaner.

I don't want to waste any more of your time on this though so if I can't
do that then I'll  just  take the hacky route  as an intermediary step,
copy out your 2009.08 recipe into my layer and mod it there.

Thanks for the time & feedback though,

Alex




[-- Attachment #2: Type: text/html, Size: 6968 bytes --]