On Tue, Apr 07, 2015 at 10:29:14AM -0600, Gary Thomas wrote:
> 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?Yes, you can generate the report in each tree separately and then compare them in one of them. > 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) Sorry, is "the same build tree" something else than "the two machines in separate trees" or are you testing both? -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
