> -----Original Message----- > From: Burton, Ross [mailto:ross.bur...@intel.com] > Sent: Friday, October 12, 2012 2:49 AM > To: Kamble, Nitin A > Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org > Subject: Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with > emgd-driver-bin > > On 12 October 2012 00:31, <nitin.a.kam...@intel.com> wrote: > > Extend the mesa-dri recipe from oecore to avoid conflict with files > > generated by emgd-driver-bin recipe. > > The commit message should also say what the high level changes were, in > this case >
The information about high level change is in the next lines in the comment. As seen in the lines bellow here. > > +# To avoid conflict disable egl, gles1, gles2 from meta-dri if the > > +BSP image # is bundling the emgd driver. > > I'm not entirely keen on this level of deep hackery, it looks very > fragile. What seems like the hackery here, is simple change to EXTRA_OECONF variable of the mesa-dri recipe. But the way original mesa-dri recipe is written, there is no simpler bitbake way to change EXTRA_OECONF. > Is there any difference in the headers installed by emgd > and mesa? Yes, there are differences, the EMGD recipe is providing GL implementation at ABI level which has not going in the open source version of mesa-dri. > An alternative would be to consider mesa a more canonical > source of GL headers for the build, and change EMGD to not install > anything to staging. This would mean that emgd wouldn't build-time > provide any virtual/libgl packages, just runtime provides so that the image > can be built using EMGD and Mesa's libgl. > There is a reason EMGD recipe is providing these GL libraries in binary form and not in the source form, I think there is EMGD specific proprietary code in these libraries. I can check with EMGD guys to confirm this. > FYI, In ross/xorg I've started re-arranging the packaging of mesa, so that the > packages are called libgl-mesa and RPROVIDE libgl. I plan to make the same > changes to EMGD once I have the shlib resolution sorted. > Looks like this kind of packaging change would not change functionality of both recipes. Cheers, Nitin > Ross _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
