Re: sstate_clean() overzealous?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2011-10-03 at 22:08 +0000, McClintock Matthew-B29882 wrote:
> On Mon, Oct 3, 2011 at 4:29 PM, Matthew McClintock <msm@freescale.com> wrote:
> > On Mon, Oct 3, 2011 at 4:24 PM, Saul Wold <saul.wold@intel.com> wrote:
> >> I am not sure that's correct, since we use sstate with the Autobuilder and
> >> it's shared across different hosts building different MACHINEs, we don't see
> >> the -natives getting build, do you have any examples?
> >
> > I'm building with targets that are not upstream, so I can't comment on
> > the upstream variant. There are different TUNES though. I'm actually
> > currently in the process of looking at why sstate-cache is not being
> > reused.
> >
> > Can you point at the autobuilder stuff? Is it going from
> > fsl-mpc8315e-rdb to and x86_64 target? Or between two x86_64 targets?
> 
> For example autoconf-native:
> 
> $ bitbake-diffsigs
> ../sstate-cache/sstate-autoconf-native-x86_64-linux-2.68-r2-x86_64-2-*siginfo
> [mattsm@right build_p5020ds_release (master *$)]$ bitbake-diffsigs
> ../sstate-cache/sstate-autoconf-native-x86_64-linux-2.68-r2-x86_64-2-*siginfo
> [snip]
> basehash changed from bab02dfa833aca4810b0fae8c4ab48f9 to
> e156f3fb86236bfc0262e6287bd73784
> List of dependencies for variable baselib changed from
> set(['BASELIB']) to set(['DEFAULTTUNE'])
> Dependency on variable BASELIB was added
> Dependency on Variable DEFAULTTUNE was removed
> Variable baselib value changed from ${BASELIB} to
> ${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or
> 'INVALID'), True) or 'lib'}
> Hash for dependent task
> virtual:native:/local/home/mattsm/git/poky/meta/recipes-devtools/autoconf/autoconf_2.68.bb.do_install
> changed from e74616029727b6e61b00273425128f1d to
> 478e7900a2310f2669708e6909883865
> 
> Back tracking this appears to be a multilib issue since I have that
> enabled on one of the -native packages:
> 
> ../meta/conf/bitbake.conf:baselib = "${BASELIB}"
> ../meta/conf/multilib.conf:baselib = "${@d.getVar('BASE_LIB_tune-' +
> (d.getVar('DEFAULTTUNE', True) or 'INVALID'), True) or 'lib'}"
> 

This is bad and shouldn't be happening, particularly for the native
packages. I did accidentally commit part of a work in progress in this
commit:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ea0b7440ec5a8663b66f56a19f0b38e803b523d3

I didn't revert it since I thought it was a good idea and fixed some
problems I was seeing.

I suspect a baselib = "lib" in native.bbclass might be a good idea
too...

Cheers,

Richard