[OE-core] sstate_clean() overzealous?

[McClintock Matthew-B29882]

On Mon, Oct 3, 2011 at 4:29 PM, Matthew McClintock <msm at freescale.com> wrote:
> On Mon, Oct 3, 2011 at 4:24 PM, Saul Wold <saul.wold at 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 at 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'}"

Which causes the other differences....

-M