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

[Nikolay Dimitrov]

Hi Otavio,

On 05/12/2015 03:41 PM, Otavio Salvador wrote:
> On Mon, May 11, 2015 at 8:42 PM, Nikolay Dimitrov <picmaster at mail.bg> wrote:
>> On 05/11/2015 08:46 PM, Otavio Salvador wrote:
>>> On Mon, May 11, 2015 at 2:24 PM, Nikolay Dimitrov <picmaster at mail.bg>
>>> wrote:
>>>>
>>>> Hi Otavio,
>>>>
>>>> On 05/11/2015 08:09 PM, Otavio Salvador wrote:
>>>>>
>>>>>
>>>>> On Mon, May 11, 2015 at 1:43 PM, Nikolay Dimitrov
>>>>> <picmaster at mail.bg> wrote:
>>>>>>
>>>>>>
>>>>>> Ping.
>>>>>
>>>>>
>>>>>
>>>>> I am building it here for testing.
>>>>
>>>>
>>>>
>>>> That's great, thanks for looking into it.
>>>
>>>
>>> Your patch can get a change:
>>>
>>> diff --git a/conf/machine/imx6dl-riotboard.conf
>>> b/conf/machine/imx6dl-riotboard.conf index bf50eaf..260deed 100644
>>> --- a/conf/machine/imx6dl-riotboard.conf +++
>>> b/conf/machine/imx6dl-riotboard.conf @@ -19,4 +19,4 @@ SERIAL_CONSOLE
>>> = "115200 ttymxc1" # FIXME: Workaround for building against
>>> linux-fslc MACHINE_EXTRA_RRECOMMENDS_remove = "fsl-alsa-plugins"
>>> PREFERRED_VERSION_imx-test = "00.00.00" -MACHINE_GSTREAMER_PLUGIN =
>>> "" +MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard = ""
>>>
>>> This makes the patch in meta-fsl-demos not needed and seems cleaner.
>>>
>>> Can you take a look and confirm?
>>
>>
>> This code sits in riotboard-specific conf file, so there's no difference
>> between MACHINE_GSTREAMER_PLUGIN and
>> MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard variables. The machine suffix
>> is redundant in the 2nd case. But even if I use the proposed
>> MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard, the fsl-image-multimedia-full
>> image build still fails.
>
> 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?

>> Regarding the meta-fsl-demos patch - the need for this fix is because
>> the packagegroup-fsl-gstreamer-full.bb is again adding the
>> gst-plugins-gl dependency, disregarding the available capabilities
>> (either hardware or kernel).
>
> See above.
>
>> So, my motivation for doing it this way for short term is the following:
>> 1. I still have single kernel to maintain (fslc) as of today.
>> 2. The board builds are broken at least since 23.April and I have to do
>> something about it.
>>
>> FYI, for a long-term solution I plan to do the following, if you agree:
>> - Support building multiple kernels, including both FSL and FSLC
>> - Somehow declare the capabilities of the hardware/kernel and take it
>> into account by in recipes. We need something like KERNEL_FEATURES and
>> MACHINE_FEATURES, and only if a feature is declared by both variables,
>> then it should be used (not sure whether this is the same as the
>> COMBINED_FEATURES mechanism). I'm looking towards your ideas here, as
>> you guys have much more Yocto experience than me.
>>
>> To summarize: my patch set is not perfect, but as of today we don't
>> have all the ingredients to make it perfect. Tomorrow we could have
>> these ingredients, but I can't see how far is this tomorrow.
>
> 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...

Regards,
Nikolay