From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 92DEAE00820; Wed, 13 May 2015 04:06:52 -0700 (PDT) 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.220.48 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-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 4D88EE0027F for ; Wed, 13 May 2015 04:06:48 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so47315690pab.3 for ; Wed, 13 May 2015 04:06:48 -0700 (PDT) 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; bh=ITmUEFQDYMTwKmK+fXwuhxRUEm/23ZlKpsegK9Ug1Dg=; b=t6LE0HuczvP502AYddHxpfPEm3uwbfQLuHSec26HboXjEXMRs5eaYuJh9b3RBDH0RW ADjkTVT/36zRe6c5TV5SYmzXYr7Cxxx996Y0tiRiYUgL5Bl8PTOtLhslnF3MS2KaKDYm Ld/KUcpYeeuHYqvlkYXqzndxI7JOcsTkq2+cAEbEBEd47WvkUnULhe4UzEE8O0N7nb1l dS1FdtnNttaxIgGavAekmF7aSZ8VaYfsJeeGIoaS7d/XHqsCbKzm7+ZCwEihV144choY 5z3uHCU64ImaG21gTp0midFjTWn8+7Y8RWkNFBks0oFjgg8JlyqWuKskLJxCsIZ4Hz6Q Kv9w== MIME-Version: 1.0 X-Received: by 10.67.4.161 with SMTP id cf1mr13727752pad.35.1431515208268; Wed, 13 May 2015 04:06:48 -0700 (PDT) Sender: otavio.salvador@gmail.com Received: by 10.70.34.109 with HTTP; Wed, 13 May 2015 04:06:48 -0700 (PDT) In-Reply-To: <5552CE65.8030507@mail.bg> References: <1430408987-24977-1-git-send-email-picmaster@mail.bg> <1430408987-24977-2-git-send-email-picmaster@mail.bg> <5550DC19.80308@mail.bg> <5550E5E3.5090502@mail.bg> <55513E7A.4060304@mail.bg> <5552CE65.8030507@mail.bg> Date: Wed, 13 May 2015 08:06:48 -0300 X-Google-Sender-Auth: m5bTIhAzV1PdnU2_G1dkuFkr6Bw Message-ID: From: Otavio Salvador To: Nikolay Dimitrov Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-demos][PATCH] riotboard: Fix broken image builds against linux-fslc 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: Wed, 13 May 2015 11:06:52 -0000 Content-Type: text/plain; charset=UTF-8 On Wed, May 13, 2015 at 1:09 AM, Nikolay Dimitrov wrote: > On 05/12/2015 03:41 PM, Otavio Salvador wrote: >> I reproduced it here. It fails only with X11 and my test was using >> Framebuffer. I have sent a patch for review. > > The patch looks ok to me. I suppose that after this fix, the RDEPENDS > hack for imx6sl is not needed anymore? It is as imx6sl does not provide the headers[1] and gst-plugins-gl fail to build. 1. http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc#n220 ... >> The biggest challenge here is how to express KERNEL_FEATURES which are >> recipe/provider specific. >> >> We have some providers: >> >> linux-fslc >> linux-imx >> linux- >> >> and each can provide different kernel features. I agree with the long >> term plan but I didn't yet came up with something which scales and >> work. > > > I'll reiterate my thoughts - it's not only the kernel features. All the > parts in the system need to consider a feature, before it's built: > - hardware > - kernel > - userspace > > A feature shouldn't be compiled and/or deployed in the image unless all > the system parts confirm its support, otherwise we'll have a failed > build or runtime issues. > > With my current limited knowledge I see 2 basic paths for implementing > this: > - 1 shared variable per feature, which is mangled across the > recipes/layers (the usual enable/disable dance); > - mechanism similar to COMBINED_FEATURES, which needs to "AND" 2 or > more sets of variables across the system. This is already done > implicitly in lots of places with heavy usage of $base_contains, but > it's not easy to read and explicit. > > // board.conf > MACHINE_FEATURES += "opengl" > > // kernel provider > KERNEL_FEATURES += "opengl" > > // image or recipe should check features indirectly > XXXXXXX_append = "${base_contains('COMBINED_FEATURES', 'opengl', > 'gst-plugins-gl', '', d)} > > Something like this... The biggest challenge here is how to express KERNEL_FEATURES which are recipe/provider specific. We have some providers: linux-fslc linux-imx linux- and each can provide different kernel features. We will need to come up with a solution to export the KERNEL_FEATURES outside of recipe namespace and make it in a clean and easy to maintain way. This is the part of puzzle still not in place. -- 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