Add PATCHRESOLVE to excluded vars for generating sstate-cache

Submitted by Matthew McClintock on Nov. 17, 2011, 10:42 p.m.

Details

Message ID 1321569767-21633-1-git-send-email-msm@freescale.com
State Accepted
Commit b64cbe0b511de8d8943ce34cbb4901239d9f0cb0
Headers show

Commit Message

Matthew McClintock Nov. 17, 2011, 10:42 p.m.
The method of resolving the patch should not effect the sstate-cache
signature.

Signed-off-by: Matthew McClintock <msm@freescale.com>
---
I'm not 100% sure about this one either - should we even generate
sstate-cache at all if we have a scenario where we try to resolve
a patch?

 meta/classes/patch.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Patch hide | download patch | download mbox

diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
index 7622163..5f9765c 100644
--- a/meta/classes/patch.bbclass
+++ b/meta/classes/patch.bbclass
@@ -138,7 +138,7 @@  python patch_do_patch() {
 			raise bb.build.FuncFailed(str(sys.exc_value))
 		resolver.Resolve()
 }
-patch_do_patch[vardepsexclude] = "DATE SRCDATE"
+patch_do_patch[vardepsexclude] = "DATE SRCDATE PATCHRESOLVE"
 
 addtask patch after do_unpack
 do_patch[dirs] = "${WORKDIR}"

Comments

Richard Purdie Nov. 25, 2011, 12:04 a.m.
On Thu, 2011-11-17 at 16:42 -0600, Matthew McClintock wrote:
> The method of resolving the patch should not effect the sstate-cache
> signature.
> 
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> I'm not 100% sure about this one either - should we even generate
> sstate-cache at all if we have a scenario where we try to resolve
> a patch?
> 
>  meta/classes/patch.bbclass |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Merged to master, thanks.

In answer to the question, there clearly shouldn't be a dependency on
this variable. We can depend on the variable even if the conditional
code using it doesn't actually use the code as the dependency analysis
doesn't account for conditional code paths.

Cheers,

Richard