[meta-freescale] [meta-fsl-arm][PATCH] gstreamer1.0-plugins-imx: add i.MX7 support

[Otavio Salvador]

On Mon, Apr 4, 2016 at 10:34 AM, Gary Bisson
<gary.bisson at boundarydevices.com> wrote:
> On Mon, Apr 4, 2016 at 3:25 PM, Otavio Salvador
> <otavio.salvador at ossystems.com.br> wrote:
>> On Mon, Apr 4, 2016 at 10:04 AM, Gary Bisson
>> <gary.bisson at boundarydevices.com> wrote:
>> ...
>>> I'm not
>>> sure why it would result in non-deterministic builds, would it be any
>>> different than the current recipe to that regard?
>>
>> Consider if one of VPU libraries were build (by hand or being a
>> dependency of any other recipe) and you later build the gstreamer-imx
>> one. It will detect and use it. So depending on the build order you
>> may have it with or without VPU support. So this is what we call a
>> non-deterministic build.
>
> But in this case we are talking about a platform which doesn't support
> VPU right? Because the one supporting it (6QDL) have VPU libs in
> DEPENDS, hence always generating the VPU plugins.
> For other platforms, the VPU package won't build since the soc is not
> compatible:
> https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-multimedia/libimxvpuapi/libimxvpuapi_0.10.1.bb#L16
>
> The same goes for a platform which doesn't support GPU. I'm just
> curious and want to understand in which case this can really happen.
>
> Anyway, considering Carlos answer I think it makes sense to wait for
> the new configuration options.

Does not matter. It has the potential of break and as such we ought to
not let it happen.

Nothing forces someone to not have a broken local recipe that brings
VPU libraries on a VPU-less platform, and gstramer-imx will than use
those. As I said, it is non-deterministic and a serial problem for
reproducible builds.

-- 
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