[OE-core] [PATCH 1/1] meta/conf/bitbake.conf: add STAMPCLEAN to BB_HASHBASE_WHITELIST

[Robert Yang]

On 03/25/2014 10:20 AM, Chris Larson wrote:
> On Mon, Mar 24, 2014 at 7:18 PM, Robert Yang <liezhi.yang at windriver.com>wrote:
>
>> The problem is that do_configure.sigdata depends on STAMPS_DIR because:
>>
>> do_configure -> STAMPCLEAN -> STAMPS_DIR
>>
>> this will make the sigdata generated by "STAMPS_DIR=/tmp/stps bitbake -S
>> recipe" doesn't match the ones in our build dir, but it should. We can
>> add STAMPS_DIR or STAMPCLEAN to BB_HASHBASE_WHITELIST to fix the
>> problem, but we can't add  STAMPS_DIR since once it is in
>> BB_HASHBASE_WHITELIST, the "STAMPS_DIR=/tmp/stps bitbake -S recipe"
>> would not run again.
>>
>> [YOCTO $6031]
>>
>> Signed-off-by: Robert Yang <liezhi.yang at windriver.com>
>>
>
> Oh good, I was hoping someone would dig into this, hadn't had the time, but
> kept noticing STAMPS_DIR was leaking in, in the bitbake-whatchanged output
> :) Nice work.
>

Thanks, the bitbake-whatchanged will work with another base-files fix now.
The left problem is that:

$ bitbake-whatchanged core-image-sato-sdk
=== Newly added tasks: (3 tasks)
   core-image-sato-sdk: do_compile do_configure do_install

Nothing should be run in fact, the root cause is that "bitbake -S recipe"
generates the sigdata file for all the tasks including noexec one, but
"bitbake recipe" doesn't generate stamps for do_populate_sysroot's
dependencies tasks when:

do_populate_sysroot[noexec] = "1"

We also have these set for a image recipe:
[snip]
do_install[noexec] = "1"
do_compile[noexec] = "1"
do_configure[noexec] = "1"
[snip]

If we remove 'do_populate_sysroot[noexec] = "1"' and keep the others,
then "bitbake recipe" will generate stamps for all the tasks including
do_install, do_compile and do_configure though they have noexec set.

I've tried to dig lib/bb/build.py, lib/bb/siggen.py and lib/bb/runqueue.py,
but didn't figure it out.

For bitbake-whatchanged, maybe we can enhance the "bitbake -S" in YP 1.7
to do the similar thing since the later one can handle the sstate tasks
(and covered task) better.

// Robert