[meta-freescale] [meta-fsl-demos][PATCH] riotboard: Fix broken image builds against linux-fslc

[Otavio Salvador]

On Wed, May 13, 2015 at 1:09 AM, Nikolay Dimitrov <picmaster at mail.bg> 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-<vendor>
>>
>> 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-<vendor>

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