[meta-freescale] [meta-fsl-arm][PATCH 1/2] add gpu-viv-bin-mx6q-dev to meta-qt5's packagegroup-qt5-toolchain-target

[Otavio Salvador]

On Thu, Feb 19, 2015 at 8:55 AM, Andreas Müller
<schnitzeltony at googlemail.com> wrote:
> On Sat, Feb 14, 2015 at 12:58 AM, Andreas Müller
> <schnitzeltony at googlemail.com> wrote:
>> On Sat, Feb 14, 2015 at 12:24 AM, Otavio Salvador
>> <otavio at ossystems.com.br> wrote:
>>> Hello Andreas,
>>>
>>> On Tue, Feb 10, 2015 at 3:44 PM, Andreas Müller
>>> <schnitzeltony at googlemail.com> wrote:
>>>> On Fri, Feb 6, 2015 at 9:39 AM, Andreas Müller
>>>> <schnitzeltony at googlemail.com> wrote:
>>>>> On Fri, Feb 6, 2015 at 2:20 AM, Otavio Salvador <otavio at ossystems.com.br> wrote:
>>>>>> Do you think it works out of box doing this change?
>>>>>>
>>>> Ok I updated to current meta-fsl-arm and would like to come back to this:
>>>>
>>>> The patch I send appended packagegroup-qt5-toolchain-target so that
>>>> GL/GLES headers were installed on the target. I've found this
>>>> necessity when testing the qt-creator patches for meta-qt5: To compile
>>>> and debug my sample projects, the headers were required.
>>>
>>> Yes, I understood it.
>>>
>>>> After building latest imx-gpu-viv I don't understand your suggestion -
>>>> maybe it was based on old gpu-viv-bin-mx6q or I misunderstand
>>>> something.
>>>
>>> Yes it was but it should be the same in imx-gpu-viv...
>>>
>>>> With current meta-fsl master the -dev packages look good to
>>>> me and I would simply append ALL dev-packages to
>>>> packagegroup-qt5-toolchain-target. The only contents added to image
>>>> are includes and pkg-config so there should be no harm.
>>>>
>>>> What do you think?
>>>
>>> I agree with the goal but you raised a point. Is it good to have the
>>> -dev packages split along subpackages?
>>>
>>> I am starting to think it is not worth it. The packaging is way more
>>> simple if we merge the -dev packages all together and to be honest
>>> from support point of view it simplifies things as well.
>>>
>>> Anyone wishing to do development is aware more resources are need. If
>>> this is a sysroot of a SDK this is not an issue but is it an issue for
>>> in-target development?
>>>
>> Aahh I see so one -dev for all - like others do.
>>
>> Coming back to my patch: For reasons I don't look though currently (OK
>> - I moved from dizzy to master for oe-core/meta-oe),
>> compiling/debugging on target with
>>
>> IMAGE_FEATURES += "dev-pkgs dbg-pkgs"
>>
>> works fine without this patch. The GL/GLES headers are all there. I
>> think this patch would have wiped away things going wrong elsewhere -
>> so I suggest to forget it.
>>
>> Andreas
> OK I had some time to look into this:
>
> What I said before is not true - seems I lost overview a bit. The
> image I am using for qt5-creator test
>
> * has NOT IMAGE_FEATURES += "dev-pkgs dbg-pkgs". Side-note: Building
> with both activated works nowadays but creates an image of 12GB!
>
> * has EGL/GLES2 and headers included but compiling a test project
> complains for missing GLES3 headers.
>
> GLES2-dev package is included in the image by package.bbclass (comment there):
>
> 'Example:  If package A depends upon package B, and A's .bb emits an
> A-dev package, this would make A-dev Recommends: B-dev.'
>
> I have many packages depending on libgles2-mx6 causing their -dev
> package(s) recommending libgles2-mx6-dev. As there is no libgles3-mx6
> package nothing depends on it -> nothing reccomends libgles3-mx6-dev.
>
> My suggestion:
>
> Simply RRECOMMEND libgles3-mx6-dev for libgles2-mx6-dev.
>
> The more I think the way you suggested to have only one -dev package,
> it scares me:
>
> * To keep upgrade paths we would need tons of RREPLACE/RPROVIDES/RCONFLICTS
> * I think the single -dev package will not be included automatically:
> imx-gpu-viv-dev package corresponds to imx-gpu-viv. That package is
> empty and nothing depends on it.
>
> Would
>
> RRECOMMENDS_libgles2-mx6-dev += "libgles3-mx6-dev"
>
> - for the time there are no glesv3 binaries - have a chance?

Yes; as it 'fails' at build I would say RDEPENDS would be better though.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750