[yocto] sstate black hole?
Paul Eggleton
paul.eggleton at linux.intel.com
Tue Jun 16 01:37:50 PDT 2015
On Monday 15 June 2015 18:19:21 Gary Thomas wrote:
> I followed this down to an i.MX6 specific package which is
> in DEPENDS:
> Variable PROVIDES value changed from
> '${PN} virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> virtual/libgles2' to
> '${PN} virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> virtual/libgles2 virtual/libgl virtual/libgles1 virtual/libgles2'
>
> Why aren't these considered the same (duplicate elements and/or order)
> should not matter for PROVIDES. Is there some way we could get bitbake
> to collapse this and remove the duplicates?
>
> I found that this happens in
> meta-fsl-arm:recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc which contains
> these lines:
> PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d"
> PROVIDES_append_mx6q = " virtual/libgl virtual/libgles1 virtual/libgles2"
> PROVIDES_append_mx6dl = " virtual/libgl virtual/libgles1 virtual/libgles2"
> PROVIDES_append_mx6sx = " virtual/libgl virtual/libgles1 virtual/libgles2"
>
> Some i.MX6 targets, nitrogen6x in particular, has overrides for both mx6q
> and mx6dl, hence the duplication.
>
> Note: I removed the extra override (for testing) and found that
> now the packages built by target A can be shared via sstate with
> target B (at least the few I tested)
I agree this would be nice, but for this to work we'd probably need to
introduce a typing system within bitbake so that it can understand that this
variable is a space-separated list. That is something we will probably do at
some point for a variety of reasons, but I don't know that it's something we
will get to soon.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the yocto
mailing list