On Mon, Apr 4, 2016 at 10:34 AM, Gary Bisson <[email protected]> wrote: > On Mon, Apr 4, 2016 at 3:25 PM, Otavio Salvador > <[email protected]> wrote: >> On Mon, Apr 4, 2016 at 10:04 AM, Gary Bisson >> <[email protected]> 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 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
