Raj, Thanks for your response.
I figured two issues I had in my original recipe. (after your response and other queries I did) a) virtual/libgl is not provided by my recipe, and I was claiming to provide it. b) I read that mesa has to provide some of the libraries, even if you have a GPU, so I added DEPENDS += "mesa" c) I also found that there is a way to remove the conflicts in the provide by doing a patch to mesa, (mesa_%.bbappend) and inside that recipe, you can do a PROVIDES_remove += "virtual/ligegl .... etc." Thanks, --Hernan > -----Original Message----- > From: Khem Raj [mailto:raj.k...@gmail.com] > Sent: Thursday, October 12, 2017 9:51 PM > To: Gutierrez, Hernan Ildefonso (Boise R&D, FW) > <hernan_gutier...@hp.com> > Cc: yocto <yocto@yoctoproject.org> > Subject: Re: [yocto] How to use two recipes to satisfy different PROVIDES -- > gpu support > > On Thu, Oct 12, 2017 at 03:33:53AM +0000, Gutierrez, Hernan Ildefonso > (Boise R&D, FW) wrote: > > Raj, > > > > Thanks for the response. > > > > Is there an example of what you mentioned below which is open source? > > > > So far my two references have been Freescale and Mali. I found mali > > much simpler than Freescale, however Mali GPU doesn't really have a > refactor of mesa, they only do a simple bbappend to mesa with the > PROVIDES_remove statement I stated in my original note. > > you can also look at meta-raspberrypi > > > > > > For reference here: https://github.com/ARM-software/meta-mali > > > > --Hernan > > > > > > > > > -----Original Message----- > > > From: Khem Raj [mailto:raj.k...@gmail.com] > > > Sent: Wednesday, October 11, 2017 7:01 PM > > > To: Gutierrez, Hernan Ildefonso (Boise R&D, FW) > > > <hernan_gutier...@hp.com> > > > Cc: yocto <yocto@yoctoproject.org> > > > Subject: Re: [yocto] How to use two recipes to satisfy different > > > PROVIDES -- gpu support > > > > > > On Wed, Oct 11, 2017 at 3:15 PM, Gutierrez, Hernan Ildefonso (Boise > > > R&D, > > > FW) <hernan_gutier...@hp.com> wrote: > > > > Hi, > > > > > > > > We have a GPU in our system. We created a recipe to satisfy all > > > > the > > > dependencies for core-image-weston (virtual/egl, virtual/libgl, > > > etc.), except virtual/mesa, which is not provided by our GPU recipe. > > > > > > > > When one builds core-image-weston, the image requires mesa to > > > > build as > > > well. > > > > > > > > Our approach to satisfy dependencies is very similar to what > > > > Freescale and > > > other vendors with Mali GPU support use, which is through the > > > following > > > statements: > > > > > > > > PREFERRED_PROVIDER_virtual/egl = "my-gpu-recipe" > > > > PREFERRED_PROVIDER_virtual/libgles1 = " my-gpu-recipe " > > > > PREFERRED_PROVIDER_virtual/libgles2 = " my-gpu-recipe " > > > > PREFERRED_PROVIDER_virtual/libgl = "my-gpu-recipe" > > > > PREFERRED_PROVIDER_virtual/mesa = "mesa" > > > > > > > > The way to remove mesa support for virtual/egl, virtual/libgles1, > > > > etc. is by > > > adding a mesa_%.bbappend where it states explicitly to remove those > > > provides from mesa recipe. > > > > > > > > e.g. > > > > PROVIDES_remove = "virtual/libgles1 virtual/libgles2 > > > > virtual/libopenvg > > > virtual/egl" > > > > > > > > > > > > The problem I am running into is that bitbake complains stating > > > > that virtual/mesa is not satisfied (Nothing PROVIDES > > > > 'virtual/mesa') > > > > > > > > When I do bitbake-layers show-recipes, I see that mesa recipe is > > > > skipped > > > because it gave priority to my-gpu-recipe. > > > > > > > > How can two recipes be used and let bitbake satisfy parts of each > recipe? > > > > > > > > Any hints will be appreciated. > > > > > > there is no easy way to control providers once a recipe is pulled in. > > > you can refactor mesa recipe like we have done for mesa and mesa-gl > > > which will mean adding a another recipe which just builds the needed > > > portions of mesa in each recipe, if your GPU driver provides > > > everything you need to run weston, then you can let it provide > > > everything that mesa provides and bitbake wont pick up mesa at all. > > > > > > > > > > > Thanks, > > > > > > > > --Hernan > > > > -- > > > > _______________________________________________ > > > > yocto mailing list > > > > yocto@yoctoproject.org > > > > https://lists.yoctoproject.org/listinfo/yocto -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto