[yocto] Prescribed way to make global variables in recipes?

[Andre McCurdy]

On Fri, Apr 8, 2016 at 10:22 AM, Andy Gikling <agikling at minnetronix.com> wrote:
> This doesn’t seem to be a viable option.  I’m still missing something I
> think.
>
> We are adding our own layer on top of our soc vendor’s layer.  In their
> layer there is a specialized u-boot recipe for the imx6 we are using.
>
> So I try to make a recipe for uboot (u-boot-faux_2014.04.bb) that includes
> the vendor’s uboot recipe with “include
> recipes-bsp/u-boot/u-boot_2014.04.bb” as suggested and try to build an image
> that is going to IMAGE_INSTALL my customized version of u-boot instead of
> the soc vendor’s.  However, I get an error at bitbake parse time saying:
>
> ERROR: Multiple .bb files are due to be built which each provide u-boot
>
> This makes sense because bitbake sees that yes, in fact now there are two
> recipes that provide u-boot.

I guess the problem here is not that you have two versions of u-boot
but that you are trying to include both of them at once - e.g. one you
added explicitly via IMAGE_INSTALL and one that the machine config
probably added via MACHINE_EXTRA_RDEPENDS or similar. To fix that,
you'll need to find a way to disable the dependency being added via
the machine config (it's not a perfect solution though because if you
then try to build an image to which you have not explicitly added a
u-boot dependency too you'll end up with a build which doesn't contain
any u-boot image at all...).

> I suppose I can do something like use
> “PREFERRED_PROVIDER_u-boot” in my local.conf, but now I need to change my
> local.conf any time I want to build a different image (ie bitbake faux-app
> and bitbake faux-app-debug).  I really want a workflow that doesn’t require
> me to change configuration files, instead just bitbake different image
> recipes.
>
> In this project I also need to conditionally patch the kernel and I’m going
> to have this same problem with multiple kernel providers as well.

If you want to change the kernel too then maybe your best option is
just to define a new machine config (you can use a similar approach as
you used for the u-boot recipe of including the original and then
over-riding just the options you want to change).

Since the machine config is a global config file which affects all
recipes, you can also use it to set the global variables etc you were
planning to use to conditionally apply u-boot patches, so you would no
longer need multiple u-boot recipes or multiple images.

> Also, I
> don’t want to remove our soc vendor’s layer to get around this error.  Their
> layer sets up the machine and all sorts of other things.  If I got rid of it
> I would need to build all that functionality into my project’s layer…  or is
> this what I’m going to need to do?
>
>
>
> Thoughts?
>
>
> ~Andy
>
>
>
> From: Burton, Ross [mailto:ross.burton at intel.com]
> Sent: Friday, April 08, 2016 10:10 AM
> To: Andy Gikling
> Cc: yocto at yoctoproject.org
> Subject: Re: [yocto] Prescribed way to make global variables in recipes?
>
>
>
>
>
> On 8 April 2016 at 16:05, Andy Gikling <agikling at minnetronix.com> wrote:
>
> So what do I do in that case? Just make two of my own versions of the
> u-boot_2014.04.bb file, and give them different names?  For example
> “u-boot-faux_2014.04.bb” and “u-boot-faux-debug_2014.04.bb” ?  That should
> work but does that make sense to do?
>
>
> As the stock u-boot appears to be sufficient I'd say use that and then add a
> u-boot-faux-debug_2014.04.bb recipe that just does "include u-boot-${PV}.bb"
> and then whatever SRC_URI changes you want in that version.
>
>
>
> Hopefully you don't need to make any fiddly changes to the recipe as PN is
> now different.
>
>
>
> Ross
>
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>