On 16-12-15 14:33, Richard Purdie wrote:
On Wed, 2015-12-16 at 14:18 +0100, 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
Sorry, yes.
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,,,
I still suspect this might be the way the tool displays the data rather
than the real problem as there is some fuzziness in the data that code
has to work with. Bitbake just knows there are dependencies on hashes
X, Y, Z and it has to try and guess how to match them up. The paths are
included to help reduce fuzz but are only used by the analysis code,
not the checksum creation.
No, if the sort order doesn't change, the checksum remains the same as well.
So if i rename "foo" to "far" it will not rebuild the package (using plain
bitbake without -S switches), but if I rename "foo" to "buz" it will rebuild
because there's a dependent package that sorts before "far" but after "buz".
Did the hashes themselves change or just the paths? I'm wondering if
the order that bitbake adds the checksums to the main checksum may have
some bearing on this...
Being able to see some real data would also help. Does this reproduce
with a public recipe I can see the real data for?
There should be quite a few recipes in OE-core that might match this pattern:
Recipe X must depend on recipe Y. The directory of Y sorts before that of X.
Renaming the directory of X to something that sorts before that of Y should
trigger the problem.
I'll see if I can locate an existing one.
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.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
