On Thu, Feb 19, 2015 at 8:55 AM, Andreas Müller <[email protected]> wrote: > On Sat, Feb 14, 2015 at 12:58 AM, Andreas Müller > <[email protected]> wrote: >> On Sat, Feb 14, 2015 at 12:24 AM, Otavio Salvador >> <[email protected]> wrote: >>> Hello Andreas, >>> >>> On Tue, Feb 10, 2015 at 3:44 PM, Andreas Müller >>> <[email protected]> wrote: >>>> On Fri, Feb 6, 2015 at 9:39 AM, Andreas Müller >>>> <[email protected]> wrote: >>>>> On Fri, Feb 6, 2015 at 2:20 AM, Otavio Salvador <[email protected]> >>>>> 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 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
