[bitbake-devel] Bug with clearing SRCREV cache

Khem Raj raj.khem at gmail.com
Wed Aug 3 02:11:12 UTC 2011


On 08/02/2011 06:24 PM, Chris Larson wrote:
> On Tue, Aug 2, 2011 at 12:06 PM, Daniel Lazzari<dlazzari at leapfrog.com>  wrote:
>> I’m not exactly sure if this is an oe-core or a bitbake bug, so I’m trying
>> here first. I noticed the other day that one of our recipes that pulls
>> source from svn and uses SRCREV = “AUTOINC” wasn’t pulling the latest
>> revision even after a cleanall. After a lot of digging, I discovered that
>> fetcher_init() was clearing the srcrev cache in “tmp-angstrom_2010_x “
>> rather than “tmp-angstrom_2010_x-uclibc”. It appears that the following line
>> in persist_data.py is the culprit:
>>
>>
>>
>>      cachedir = (bb.data.getVar("PERSISTENT_DIR", d, True) or
>>
>>                  bb.data.getVar("CACHE", d, True))
>>
>>
>>
>> PERSISTENT_DIR doesn’t evaluate to the correct value. Changing it to just
>> pull from CACHE seems to fix it, but I’m not sure how important
>> PERSISTENT_DIR is or even what it does.
>
> What do you mean by "the correct value" here? PERSISTENT_DIR is
> exactly what it sounds like, the location where persist_data stores
> its database(s), that's it.

Actually in oe-core, original TMPDIR gets appended

meta/conf/distro/defaultsetup.conf:TCLIBCAPPEND ?= "-${TCLIBC}"
meta/conf/distro/defaultsetup.conf:TMPDIR_append = "${TCLIBCAPPEND}"

but this probably happens late in the parse cycle. So it creates

bb_codeparser.dat  bb_persist_data.sqlite3

in both TMPDIR and TMPDIR-uclibc or TMPDIR-eglibc whatever libc you are 
using.

Ideally I would have thought that TMPDIR is evaluated to final value 
before its used

Thanks
-Khem




More information about the bitbake-devel mailing list