[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