linux/poky.git/meta/classes/sstate.bbclass, branch 1.6_M5

sstate: list missing files for toaster

2014-03-21T12:05:53+00:00

Toaster needs to record the attempts to restore setscene tasks that don't have a sstate file. We build a list of tasks for which we can't find an sstate file, and if we're running under Toaster data collection, we send it off with a MetadataEvent. (From OE-Core rev: 109ae6c5c981610ab0d63d2c83dcd50b2e93276b) Signed-off-by: Alexandru DAMIAN Signed-off-by: Richard Purdie

classes/sstate: don't overwrite buildhistory vardepsexclude

2014-03-11T15:11:41+00:00

This was stomping over the value added in buildhistory.bbclass, leading to task signatures *still* changing when buildhistory was added to INHERIT. Fixes [YOCTO #5897]. (From OE-Core rev: f7a0aa412a921a41d301be072cedcda2662ffbd7) Signed-off-by: Paul Eggleton Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

sstate: Ensure SSTATEPOSTINSTFUNCS is accounted for in signatures

2014-03-05T15:50:20+00:00

Bitbake can't interpret the python execution of these functions so include the dependency manually. [YOCTO #4507] (From OE-Core rev: 39c53d26a1ea0859ca30456b6af0a28b2ea16769) Signed-off-by: Richard Purdie

sstate: Drop 'SafeDep' code from setscene validation function

2014-02-25T08:01:09+00:00

I have a feeling this code exists from the time before we had proper coverage of one sstate task by another task. At that time it was a "poor" persons version of that idea, we now have much better code internal to bitbake which handles this. Worse, this code actually breaks certain rebuild scenarios, e.g.: bitbake libtool-cross bitbake libtool-cross -c cleansstate rm tmp -rf bitbake libtool-cross would fail as binutils-cross wasn't installed from sstate. The easiest fix is to remove the obsolete/broken code. [YOCTO #5773] (From OE-Core rev: ccad07f35fb7f959e24fd50d04c7d10dd5cf20d0) Signed-off-by: Richard Purdie

classes/sstate: fix taints being undone on execution of sstate tasks

2014-02-25T08:01:09+00:00

The code here that deletes stamps was also deleting the taint files; so forcing an sstate task with -f would force it to execute and then because the taint file was deleted in the process, the next execution would simply restore the output from sstate again. We need to exclude the taint files just like we did in bb.build.make_stamp(). Fixes [YOCTO #5805]. (From OE-Core rev: 4708859e5627488251dc4250d45cb5f4e9736b8a) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

sstate: Exclude SSTATE_EXTRAPATH from checksums

2014-02-11T17:15:54+00:00

After the change to allow target recipes to depend on native recipes, the native checksums becomes all the more critical. Add to this that we're now accounting for pre/postfuncs and we have a cache reuse issue since the distro LSB string is getting coded in when it shouldn't be. This excludes that string and allows one set of native sstate to share checksums with another set from a different host distro. They're separated into different directories so this is fine for our use cases. (From OE-Core rev: 1fa7d4331d994b9eeb6f973d1a1f04cb4df92c13) Signed-off-by: Richard Purdie

sstate: Improve funciton checksums

2014-02-04T22:51:43+00:00

Now that bitbake is recursing into pre/postfuncs, we need to ensure the dependencies of these functions is correct. We don't want dependencies on MACHINE or other related variables. This patch adds in appropriate variable exclusions to achieve this. (From OE-Core rev: 8461283a648d7c5affd51971ebd9b35a8a4c625f) Signed-off-by: Richard Purdie

sstate.bbclass: remove previous version's stamp

2014-01-21T10:45:29+00:00

There is a potential problem if we don't remove the previous version's stamp, for example: The depend chain is: libtool-native -> autoconf-native -> m4-native We have two m4-native: 1.4.9 and 1.4.7 1) Clean all of them to make a fresh build so that we can reproduce the problem $ bitbake m4-native autoconf-native libtool-native -ccleansstate 2) Build libtool-native so that the m4-native_1.4.17 will be built $ bitbake libtool-native 3) Set PREFERRED_VERSION_m4-native = "1.4.9" and build again $ bitbake libtool-native 4) Set PREFERRED_VERSION_m4-native = "1.4.17" and build again $ bitbake libtool-native -ccleansstate && bitbake libtool-native Then the build will fail: [snip] | m4: unrecognized option '--gnu' | Try `m4 --help' for more information. | autom4te: m4 failed with exit status: 1 [snip] The is because when we change m4-native to 1.4.17 and build libtool-native again: 5) libtool-native depends on autoconf-native, and autoconf-native's version isn't change, so it can remove the current stamp and mirror the sstate (the one depends on m4-native_1.4.9) from the SSTATE_DIR correctly. 6) The mirrored autoconf-native depends on m4-native_1.4.17's do_populate_sysroot, and the stamp is already there (which is made by step 2), so it would do nothing, but this is incorrect, since the one that really in the sysroot is m4-native_1.4.9, then the error happens. Remove previous version's stamp in sstate_clean() will fix the problem. [YOCTO #5422] (From OE-Core rev: 4659d29b1040349116549644e45035a5b37d9311) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

sstate: add do_package to the noexec list in setscene_depvalid

2014-01-07T13:58:32+00:00

do_package doesn't exist and are noexec anyway for native/cross/crosssdk packages. (From OE-Core rev: 1028ac813fa9803ebfff6bcfa7f8b67012609b27) Signed-off-by: Ming Liu Signed-off-by: Richard Purdie

sstate: Add optimizing logic for crosssdk setscene dependencies

2014-01-06T22:17:33+00:00

This patch mainly aims to add optimisation for crosssdk setscene dependency validating which we haven't handled in current logic, and which I think we could have as we've already implemented to native/cross, although there are albeit not many crossdk tasks, we could still get some performance enhancement. (From OE-Core rev: 1094983ff87a8b745a5bc7bfe9514433ee3c4ad2) Signed-off-by: Ming Liu Signed-off-by: Richard Purdie