[OE-core] How to find out why shared sstate is not being used for a recipe

Richard Purdie richard.purdie at linuxfoundation.org
Tue Jun 3 14:10:15 UTC 2014


On Tue, 2014-06-03 at 15:54 +0200, Mike Looijmans wrote:
> On 06/03/2014 10:45 AM, Richard Purdie wrote:
> > the next steps depend upon how clear the differences are. Basically
> > there should be some degree of commonality between the two builds and at
> > some point there will be divergence. We need to pinpoint the point of
> > divergence. The divergence will be in fpga-image-miami itself or in one
> > of its dependencies.
> 
> ALL stamps for ALL tasks for fpga-image-miami are different. There's a few 
> thousand lines in these files, with very few similarities.

Ok, this gives a very strong pointer then, see below.

> I'll just go for the "do_fetch" task then, since that's about the first to 
> execute.

This is a good move.

> So far, on one project (that is, NOT the fpga-image-miami) the SRC_URI is 
> slightly different. The machines are on various sides of a router/firewall, so 
> SRC_URI="git://${MY_SERVER}/blabla" evaluates differently.
> 
> How can I tell the system that the value of "MY_SERVER" is irrelevant to each 
> and every build step in each and every recipe?

The SRC_URI changing would indeed cause the tasks build separately since
bitbake thinks they're different things.

You have two ways of addressing this. Firstly, you could setup PREMIRROR
entries for these git urls which remaps them to the correct thing in
each case. There would then be one "canonical" url in the recipe and
you'd not need to change the hash generation.

The other way would be to either exclude the variable from the checksum
generation or give it a specific value. This would be something like:

do_fetch[vardepsexclude] += "SRC_URI"

you may also have to do this with other tasks that use SRC_URI such as
do_unpack and do_patch. The other option is:

SRC_URI[vardepvalue] = "git://canonical/url/for/recipe"

which gives it a specific value to use for checksum purposes.

Cheers,

Richard




More information about the Openembedded-core mailing list