[yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
Darren Hart
darren.hart at intel.com
Tue Oct 16 15:20:50 PDT 2012
On 10/16/2012 03:17 PM, Kamble, Nitin A wrote:
>
>
>> -----Original Message-----
>> From: Hart, Darren
>> Sent: Monday, October 15, 2012 9:10 AM
>> To: Kamble, Nitin A
>> Cc: Zanussi, Tom; yocto at yoctoproject.org
>> Subject: Re: [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-
>> driver-bin
>>
>> On 10/11/2012 04:31 PM, nitin.a.kamble at intel.com wrote:
>>> From: Nitin A Kamble <nitin.a.kamble at intel.com>
>>>
>>> Extend the mesa-dri recipe from oecore to avoid conflict with files
>>> generated by emgd-driver-bin recipe.
>>>
>>> This extention is needed only when emgd-driver-bin recipe is included
>>> in the target image, so the code is conditional to run only on the
>>> machine with emgd graphics driver.
>>>
>>> The emgd binary driver also provides egl, gles1, gles2 library & headers.
>>> To avoid conflict disable egl, gles1, gles2 from meta-dri if the BSP
>>> image is bundling the emgd driver.
>>>
>>> This commits avoids these build warning
>>>
>>> WARNING: The recipe is trying to install files into a shared area when those
>> files already exist. Those files are:
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/KHR/khrplatform.h
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/EGL/eglplatform.h
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/EGL/eglext.h
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/EGL/egl.h
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/GLES/glplatform.h
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/GLES/gl.h
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/GLES/glext.h
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2ext.h
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2.h
>>>
>>> /srv/home/nitin/build-test-bsps/build-
>> crownbay/tmp/sysroots/crownbay/u
>>> sr/include/GLES2/gl2platform.h
>>>
>>> This resolves part of the issue reported on the bug:
>>> [Yocto #3238]
>>>
>>> Signed-off-by: Nitin A Kamble <nitin.a.kamble at intel.com>
>>> ---
>>> .../recipes-graphics/mesa/mesa-dri_8.0.4.bbappend | 24
>> ++++++++++++++++++++
>>> 1 files changed, 24 insertions(+), 0 deletions(-) create mode 100644
>>> common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
>>>
>>> diff --git a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
>>> b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
>>> new file mode 100644
>>> index 0000000..6bfa968
>>> --- /dev/null
>>> +++ b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
>>> @@ -0,0 +1,24 @@
>>> +
>>> +# The emgd binary driver also provides egl, gles1, gles2 library & headers.
>>> +# To avoid conflict disable egl, gles1, gles2 from meta-dri if the
>>> +BSP image # is bundling the emgd driver.
>>> +
>>> +python __anonymous () {
>>> + import re
>>> + xserver = d.getVar('XSERVER', True)
>>> + if 'emgd-driver-bin' in xserver.split(' '):
>>> + extra_oeconf = d.getVar('EXTRA_OECONF', True).split()
>>> + take_out = ["--enable-egl", "--enable-gles1", "--enable-gles2"]
>>> + put_in = ["--disable-egl", "--disable-gles1", "--disable-gles2"]
>>> + pattern = re.compile("--with-egl-platforms")
>>> + new_extra_oeconf = [ ]
>>> + for i in extra_oeconf:
>>> + if ( i not in take_out ) and ( not pattern.match(i)):
>>> + new_extra_oeconf.append(i)
>>> + for i in put_in:
>>> + new_extra_oeconf.append(i)
>>> +
>>> + d.setVar('EXTRA_OECONF', ' '.join(new_extra_oeconf))
>>> + depends = d.getVar('DEPENDS', True)
>>> + d.setVar('DEPENDS', depends + " emgd-driver-bin")
>>
>> Odd mix of whitespace and tabs above.
>>
>> Also, I have to agree with Ross. This places very specific knowledge of an
>> external package in the general purpose recipe. This is opposite of how these
>> things should be built up.
>>
>
> Whitespace issues can be solved easily. But if this solution is not acceptable, then I am not sure how to solve the issue. Do we push the issue to 1.4?
Can you define a variable that EXTRA_OECONF includes which can be
manipulated in a bbappend in the meta-intel? This would keep this
complex logic out of the core recipe and move into the place that
actually needs it.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
More information about the yocto
mailing list