[yocto] sstate black hole?

[Gary Thomas]

On 2015-04-07 10:19, Martin Jansa wrote:
> On Tue, Apr 07, 2015 at 08:52:36AM -0600, Gary Thomas wrote:
>> I'm building for multiple ARM i.MX6 platforms.  These have
>> the same SoC, but slightly different peripherals. As far as
>> I can tell, they should be able to share everything except
>> for a few ${MACHINE} specific packages, e.g. the kernel and
>> u-boot.
>>
>> Sadly, that doesn't seem to be the case.  The architecture
>> specific packages are being split into two categories - plain
>> ARM/Cortex-A9 and those that have i.MX6 specific optimizations.
>> For example, after building a complete image (on the order of
>> core-image-sato), I have this split:
>> $ ls tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/
>> acl                  gst-player                 libsamplerate0         modutils-initscripts  shadow-sysroot
>> alsa-utils           gst-plugins-bad            libsm                  mpeg2dec              shared-mime-info
>> apmd                 gst-plugins-good           libsndfile1            mplayer2              speex
>> atk                  gst-plugins-ugly           libsoup-2.4            mtdev                 sqlite3
>> attr                 gstreamer                  libtheora              ncurses               startup-notification
>> base-passwd          gstreamer1.0               libtirpc               neon                  strace
>>      ...
>> gst-ffmpeg           libpostproc                matchbox-wm            scrnsaverproto        zlib
>> gst-fluendo-mpegmux  libproxy                   mkfontdir              settings-daemon
>> gst-meta-base        libpthread-stubs           mkfontscale            shadow
>>
>> $ ls tmp/work/cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi/
>> alsa-lib      gst-plugins-base           imx-gpu-viv  libfslparser   libsdl      xf86-video-imxfb-vivante
>> cairo         gstreamer1.0-plugins-bad   libdrm       libfslvpuwrap  mesa        xserver-xorg
>> firmware-imx  gstreamer1.0-plugins-base  libfslcodec  libglu         pulseaudio
>>
>> It's the second category that is causing problems.  They do not
>> seem to end up in any shareable sstate at all.  If I try to rebuild
>> using only sstate, i.e. build my complete image to success, then
>> remove 'tmp' and rebuild, using the sstate-cache from the first go,
>> all of the above packages (alsa-lib, ..., xserver-xorg) are all
>> rebuilt from scratch.  Those recipes do seem to end in my sstate-cache,
>> but they are never reused from it.
>>
>> What would make this happen?  How can I prevent it?
>>
>> As is, sstate is not really shareable between these i.MX6 targets
>> as so much is being rebuilt all the time...
>>
>> Any ideas or pointers gladly welcomed.
>
> Try openembedded-core/scripts/sstate-diff-machines.sh
> to see why.
>

Can this work if I build for the two machines in separate trees?
Also, I'm really trying to find out why a build for the same machine
doesn't reuse sstate, in the same build tree, back-to-back builds
(no metadata changes)

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