Re: [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin

[Darren Hart <darren.hart@intel.com>]

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@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@intel.com wrote:
>>> From: Nitin A Kamble <nitin.a.kamble@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@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