On 05-10-15 12:18, Richard Purdie wrote:
On Mon, 2015-10-05 at 11:34 +0200, Mike Looijmans wrote:
I've been puzzling with this for many hours now, but I can't seem to figure
this out.
I have a recipe that doesn't mention MACHINE anywhere, but still the
sstate-cache won't be re-used for other machines, because OE somehow insists
the package does depend on $MACHINE.
The workaround I could find is to put something like this in the recipe:
MACHINE[vardepvalue] = "any"
(Similar stupid hacks like "vardepsexclude" will probably work too, but I'm
not interested in forcing this particular recipe, but I'm trying to figure out
what makes bitbake think it matters)
Since it builds for an FPGA type, the package has
PACKAGE_ARCH="${FPGA_FAMILY}" set, and FGPA_FAMILY is set in local.conf.
When switching machines, "bitbake -S printdiff fpga-image-dyplo-test" reports
that MACHINE changed and that is what caused sstate not beign reused. But the
recipe does not use anything related to $MACHINE at all.
Is there a way to make it tell me WHY it thinks that MACHINE is important to
the recipe?
Very briefly (sorry travelling), find the task that you want to know
more around and find the sigdata file in the stamps directory for it.
Run "bitbake-diffsigs <sigdatafile>" and it will show you how the
dependencies are calculated. You can compare two sigdata files using the
same command, "bitbake-diffsigs <sigdatafile1> <sigdatafile2>".
Thanks, that reveiled the issue.
I was smart in local.conf and calculated the FPGA name from the MACHINE name.
That yields the same word, but somehow the dependency on the MACHINE variable
is kept.
A simple fix is then to just use a ":=" assignment for FPGA_FAMILY so that the
link to MACHINE is lost, but that then results in another rebuild:
List of dependencies for variable FPGA_FAMILY changed from
'set(['MACHINE'])' to 'set([])'
Dependency on Variable MACHINE was removed
The FPGA packages take long to build (4 hours for just one is no exception, on
an i7 machine) so preventing them to be rebuilt is really important here.
But having found the issue, I guess after a round of rebuilds, it'll go away
now.
For the bigger picture:
If I have a recipe that says:
X = "x"
And I refactor it a bit to read:
Y = "x"
X = "${Y}"
What is the logic behind having to rebuild the package now? Why does the
'source' of the contents matter to the hash? It won't generate different
output, regardless whether X is 'calculated' or just 'constant'.
In particular, I've noticed this happening when switching between AUTOREV and
a fixed revision in a recipe.
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: [email protected]
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
