[yocto] [sstate-cache] using sstate-cache in parallel builds
ross.burton at intel.com
Thu Nov 3 03:44:14 PDT 2016
On 3 November 2016 at 09:57, Mike Looijmans <mike.looijmans at topic.nl> wrote:
> Would it be safe to store the sstate-cache for a bunch of builds into a
> single directory, with builds running in parallel contributing to that?
> Each build would be using a different set of layers, different machines,
> and building different images, but there would be a lot of common things
> (usually they all refer to the same OE branches).
> We use a build server to share out sstate-cache for various builds, but as
> projects are getting added, it's getting more complicated with projects
> using the sstate-caches of other projects. It would make things quite
> simple if all builds just pointed to the same sstate-cache directory, so
> they could share whatever they want.
Mine all share a single sstate cache, as that's pretty much the point. If
you're targetting different machines then there's a pretty good chance
there's no overlap anyway.
sstate fetch is basically "does a file with this recipe+sha exist", so as
long as files are written atomically then there's no race conditions.
sstate write is done atomically to a temporary file which then then mv'd
to the real filename, so the only race here is that two parallel bitbakes
doing exactly the same build configuration (ie, same hash) can both not
find anything in sstate, both rebuild, and both write to sstate. As the
write is atomic, worst case is more work done than required.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the yocto