[yocto] sstate-cache and native recipes

[Gary Thomas]

On 2017-01-18 10:13, Gary Thomas wrote:
> I've been trying to understand (as was recently posted here by
> another user) why native recipes are not being well shared/reused
> by the sstate-cache mechanism.  I have a build machine where I
> do lots of builds for various targets.  I would think (hope!)
> that xxx-native packages would be the same for every build and
> if I have the sstate mirror set up correctly, be shared appropriately.
> To this end, I have one "master" build that I always run first
> whenever the metadata changes, then point all the other builds
> at that tree.
>
> For the most part, this works pretty well, but there are still
> some places where it doesn't.  Here are a couple of examples
> which I've investigated:
>
> * glib-2.0-native depends on ${DISTRO_FEATURES}
>   To me this seems silly as "native" should be "native" and
>   not depend on any distribution settings.  Here's the code
>   that's causing it (in do_install)
>
>         if [ -f ${D}${datadir}/installed-tests/glib/gdbus-serialization.test ]; then
>                 if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false", "true", d)}; then
>                         rm ${D}${datadir}/installed-tests/glib/gdbus-serialization.test
>                 fi
>         fi
>
>   Obviously this isn't important for a native package.  Any
>   suggestions on how I might keep this from creeping in?

BTW, once glib-2.0-native can't be shared, a number of other native
packages will also have to be rebuilt because of build dependencies.
I discovered this when qemu-native was being rebuilt on almost all
of my targets...

>
> * xxx-native packages are not shared if ${DISTRO} is different.
>   Again, this seems wrong as "native" packages should really only
>   depend on the build ${HOST}, not ${DISTRO}
>
> I'm looking at this for the sole purpose of reducing the load on my
> build machine.  Any package that can be shared and not have to be
> rebuilt just makes it more productive :-)
>
> Thanks for any ideas or comments
>


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------