From: Mike Looijmans <mike.looijmans@topic.nl>
To: "OE Core (openembedded-core@lists.openembedded.org)"
<openembedded-core@lists.openembedded.org>
Subject: Re: How to find out why shared sstate is not being used for a recipe
Date: Mon, 18 Aug 2014 10:12:46 +0200 [thread overview]
Message-ID: <53F1B57E.3040902@topic.nl> (raw)
In-Reply-To: <53843793.3030309@topic.nl>
On 05/27/2014 08:58 AM, Mike Looijmans wrote:
> I have a deja-vu feeling about this question.
>
> I have this recipe:
>
> https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image-miami.bb
>
>
> Which includes this one:
> https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc
>
>
> I have a build server that exports its sstate-cache directory through HTTP,
> and a local host that attempts to use that sstate-cache. This works fine,
> except for the recipe above. Building this recipe takes about 1 hour, so i
> really really really want to share that state at any cost. As you can see,
> I've done a big shotgun blast of "vardepdsexclude" to get the recipe to be as
> common as possible. Still any host wants to build its own version.
>
I recently figured out the cause of this:
LIC_FILES_CHKSUM =
"file://${META_ZYNQ_BASE}/COPYING;md5=751419260aa954499f7abaabaa882bbe"
The META_ZYNQ_BASE variable is set to the overlay path in the layer.conf file.
This path varies on different machines.
I added the following line to layer.conf to prevent this from happening:
META_ZYNQ_BASE[vardepvalue] = "meta-zynq"
This triggered a rebuild of all pacakges that I've seen to have this sstate
problem, thereby confirming that this really was the cause.
It DID surprise me that the LIC_FILES_CHKSUM full path filename somehow ended
up in the hash for the package's contents. It would have been better to only
include the license contents itself (or its checksum).
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
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@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Bezoek ons op 9 en 10 september tijdens Technology for Health Den Bosch (stand 53)
http://www.technologyforhealth.nl
prev parent reply other threads:[~2014-08-18 8:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 6:58 How to find out why shared sstate is not being used for a recipe Mike Looijmans
2014-05-28 20:42 ` Khem Raj
2014-05-28 20:46 ` Christopher Larson
2014-05-28 23:12 ` Richard Purdie
2014-06-03 5:25 ` Mike Looijmans
2014-06-03 5:35 ` Mike Looijmans
2014-06-03 8:45 ` Richard Purdie
2014-06-03 13:54 ` Mike Looijmans
2014-06-03 14:10 ` Richard Purdie
2014-06-04 6:19 ` Mike Looijmans
2014-06-04 10:44 ` Mike Looijmans
2014-06-03 8:32 ` Martin Jansa
2014-06-03 9:07 ` Richard Purdie
2014-08-18 8:12 ` Mike Looijmans [this message]
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=53F1B57E.3040902@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