aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/gen-lockedsig-cache
AgeCommit message (Collapse)Author
2015-12-01scripts/gen-lockedsig-cache: improve outputPaul Eggleton
* Print some status when running * When incorrect number of arguments specified, print usage text Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-10-19scripts/gen-lockedsig-cache: fix race with temp file creationPaul Eggleton
As part of populating the sstate-cache with an artifact (.tgz file) we create a temp file and then atomically move it to the final name. Due to the glob used in this script such temp files were being matched, and between the time they were matched and the time the script started copying files, the temp file may have vanished. This fixes random "No such file or directory" failures building the extensible SDK on build setups where the sstate-cache directory is shared amongst multiple build machines. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-02-23gen-lockedsig-cache: Allow cross-filesystem copies.Randy Witt
Since this previously always tried to use hardlinks you couldn't have the source and destination be on different devices. This change allows for that and also prevents failure in situations where the files already existed. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-17sstatesig/sstate: Add support for locked down sstate cache usageRichard Purdie
I've been giving things some thought, specifically why sstate doesn't get used more and why we have people requesting external toolchains. I'm guessing the issue is that people don't like how often sstate can change and the lack of an easy way to lock it down. Locking it down is actually quite easy so patch implements some basics of how you can do this (for example to a specific toolchain). With an addition like this to local.conf (or wherever): SIGGEN_LOCKEDSIGS = "\ gcc-cross:do_populate_sysroot:a8d91b35b98e1494957a2ddaf4598956 \ eglibc:do_populate_sysroot:13e8c68553dc61f9d67564f13b9b2d67 \ eglibc:do_packagedata:bfca0db1782c719d373f8636282596ee \ gcc-cross:do_packagedata:4b601ff4f67601395ee49c46701122f6 \ " the code at the end of the email will force the hashes to those values for the recipes mentioned. The system would then find and use those specific objects from the sstate cache instead of trying to build anything. Obviously this is a little simplistic, you might need to put an override against this to only apply those revisions for a specific architecture for example. You'd also probably want to put code in the sstate hash validation code to ensure it really did install these from sstate since if it didn't you'd want to abort the build. This patch also implements support to add to bitbake -S which dumps the locked sstate checksums for each task into a ready prepared include file locked-sigs.inc (currently placed into cwd). There is a function, bb.parse.siggen.dump_lockedsigs() which can be called to trigger the same functionality from task space. A warning is added to sstate.bbclass through a call back into the siggen class to warn if objects are not used from the locked cache. The SIGGEN_ENFORCE_LOCKEDSIGS variable controls whether this is just a warning or a fatal error. A script is provided to generate sstate directory from a locked-sigs file. (From OE-Core rev: 7e14784f2493a19c6bfe3ec3f05a5cf9797a2f22) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>