On Sat, Feb 14, 2015 at 12:58 AM, Andreas Müller <schnitzelt...@googlemail.com> wrote: > On Sat, Feb 14, 2015 at 12:24 AM, Otavio Salvador > <ota...@ossystems.com.br> wrote: >> Hello Andreas, >> >> On Tue, Feb 10, 2015 at 3:44 PM, Andreas Müller >> <schnitzelt...@googlemail.com> wrote: >>> On Fri, Feb 6, 2015 at 9:39 AM, Andreas Müller >>> <schnitzelt...@googlemail.com> wrote: >>>> On Fri, Feb 6, 2015 at 2:20 AM, Otavio Salvador <ota...@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 -- _______________________________________________ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
