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/8046479967Comment 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.
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