From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id DA210E00815; Thu, 19 Feb 2015 03:01:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.213.46 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 09F96E00546 for ; Thu, 19 Feb 2015 03:01:33 -0800 (PST) Received: by yhab6 with SMTP id b6so4246746yha.10 for ; Thu, 19 Feb 2015 03:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gxGut4P62BEvMSFJh1b0mFTXNN8ZqWockh7sljS703Q=; b=gDBluMwobycKS/ob0vZrwXXrRWw5ELTBiSv7x4steIJEyv8IFPbkCBmxz08OGPJ7O6 6e3WyP/gT//JkNNi137hPnlHfqOWjSeI8BZh0bNPGlocZKdKH3spGarvTsKicWEdOeNp xBopxzs/1Zw23XDejj71aLzZH3mYUYt2OddCh7jR9jq/in/E3hl1YFwUC8hYyQ/9fGHl f/PbBnY9nFwAYlBqymjO/++XfPvI7ZCRq4h6AEOLhzSHSrUEclbQu/udSnn5UQVZBr59 uB8h6fmoD547/hKJSqVlYjE56iNIenjW1qxZC7txNAYbS2r4PkC3pYwnN/PMZcZw6Ql8 OGng== MIME-Version: 1.0 X-Received: by 10.236.229.200 with SMTP id h68mr2408372yhq.90.1424343693155; Thu, 19 Feb 2015 03:01:33 -0800 (PST) Sender: otavio.salvador@gmail.com Received: by 10.170.123.133 with HTTP; Thu, 19 Feb 2015 03:01:33 -0800 (PST) In-Reply-To: References: <1422370818-10095-1-git-send-email-schnitzeltony@googlemail.com> <1422370818-10095-2-git-send-email-schnitzeltony@googlemail.com> Date: Thu, 19 Feb 2015 09:01:33 -0200 X-Google-Sender-Auth: fnvJf-u1oIRpHZRzeUMSkeM-DOI Message-ID: From: Otavio Salvador To: =?UTF-8?Q?Andreas_M=C3=BCller?= Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm][PATCH 1/2] add gpu-viv-bin-mx6q-dev to meta-qt5's packagegroup-qt5-toolchain-target X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 11:01:34 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 19, 2015 at 8:55 AM, Andreas M=C3=BCller wrote: > On Sat, Feb 14, 2015 at 12:58 AM, Andreas M=C3=BCller > wrote: >> On Sat, Feb 14, 2015 at 12:24 AM, Otavio Salvador >> wrote: >>> Hello Andreas, >>> >>> On Tue, Feb 10, 2015 at 3:44 PM, Andreas M=C3=BCller >>> wrote: >>>> On Fri, Feb 6, 2015 at 9:39 AM, Andreas M=C3=BCller >>>> wrote: >>>>> On Fri, Feb 6, 2015 at 2:20 AM, Otavio Salvador 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 th= is: >>>> >>>> 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 +=3D "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 +=3D "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 th= ere): > > '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/RCONFLIC= TS > * 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 +=3D "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. --=20 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