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

[Andreas Müller]

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?

Andreas