[yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
From: Nitin A Kamble
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/usr/include/GLES2/gl2platform.h
This resolves part of the issue reported on the bug:
[Yocto #3238]
Signed-off-by: Nitin A Kamble
---
.../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 000..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")
+}
--
1.7.3.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
On 12 October 2012 00:31, 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 > +# 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. Is there any difference in the headers installed by emgd and mesa? 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. 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. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
> -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, 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
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
On 10/11/2012 04:31 PM, nitin.a.kam...@intel.com wrote:
> From: Nitin A Kamble
>
> 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/usr/include/GLES2/gl2platform.h
>
> This resolves part of the issue reported on the bug:
> [Yocto #3238]
>
> Signed-off-by: Nitin A Kamble
> ---
> .../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 000..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.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
> -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.kam...@intel.com wrote:
> > From: Nitin A Kamble
> >
> > 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
> > ---
> > .../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 000..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?
Nitin
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
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.kam...@intel.com wrote:
>>> From: Nitin A Kamble
>>>
>>> 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
>>> ---
>>> .../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 000..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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-driver-bin
> >>>
> >>> 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 000..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.
If we can modify the recipe in poky, then this method is not needed to achieve
same thing. But because of release we may not be able to do it.
Nitin
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
