From: Mike Looijmans <mike.looijmans@topic.nl>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: How to move a recipe to another directory without invalidating its sstate-cache?
Date: Wed, 16 Dec 2015 14:26:01 +0100 [thread overview]
Message-ID: <56716669.6040503@topic.nl> (raw)
In-Reply-To: <567164AF.1040405@topic.nl>
On 16-12-15 14:18, Mike Looijmans wrote:
> On 16-12-15 13:35, Richard Purdie wrote:
>> On Wed, 2015-12-16 at 10:38 +0100, Mike Looijmans wrote:
>>> I renamed "recipes-some/foo/bar.bb" to "recipes-some/buzz/bar.bb"
>>>
>>> Rebuilding bar and its dependencies will take about 16 hours. So I
>>> don't want
>>> to trigger a rebuild.
>>>
>>> running "bitbake -S printdiff bar" only reveils this:
>>
>> I'm not sure I trust the output of -S printdiff, there are some cases
>> it doesn't seem to "guess" right. I wish I or someone one could fix but
>> but we can do its work manually. Can you try something like:
>>
>> set TMPDIR = "x"
>> bitbake -S bar
>> rename the recipe
>> set TMPDIR = "y"
>> bitbake -S bar
>
> Found out I need an extra "none" in here:
> bitbake -S none bar
>
>>
>> then
>>
>> "ls tmp-x/stamps/xxxx/bar"
>> "ls tmp-y/stamps/xxxx/bar"
>>
>> and see which tasks change signature. Then run:
>>
>> "bitbake-diffsigs <sig A> <sig B>"
>>
>> and see if that makes more sense?
>
> That gave the same output. Everything after "runtaskdeps" is bogus because its
> value changes from [blahblah, foobar] into [buzbar, blahblah] and now diffsig
> seems to attempt to match the "blahblah" signatures against those of "buzbar".
>
> Which sort of hints that if my new name starts with an "f" the reordering
> won't happen, so I'm gonna try renaming to "fbuz" now,,,
>
Indeed.... If I rename the directory without affecting the sort order of that
array, in this situation, "fbuz" instead of "buz", the signatures will match
again, and it won't rebuild.
Looks like the problem is the way the "runtaskdeps" are sorted.
If a recipe depends on another recipe say "X", moving the recipe to a
directory which sorts to the other side of "X" will trigger a rebuild at some
stage.
M.
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
next prev parent reply other threads:[~2015-12-16 13:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 9:38 How to move a recipe to another directory without invalidating its sstate-cache? Mike Looijmans
2015-12-16 12:35 ` Richard Purdie
2015-12-16 13:18 ` Mike Looijmans
2015-12-16 13:26 ` Mike Looijmans [this message]
2015-12-16 13:33 ` Richard Purdie
2015-12-17 6:24 ` Mike Looijmans
2015-12-17 12:47 ` Mike Looijmans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56716669.6040503@topic.nl \
--to=mike.looijmans@topic.nl \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox