On Fri, Apr 8, 2016 at 10:22 AM, Andy Gikling <agikl...@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.bur...@intel.com] > Sent: Friday, April 08, 2016 10:10 AM > To: Andy Gikling > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Prescribed way to make global variables in recipes? > > > > > > On 8 April 2016 at 16:05, Andy Gikling <agikl...@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@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto