Hi,
Just realized this change was never merged into master, so see this as a friendly reminder about this change-set (might have been lost in the flood of changes in this time-frame). Not the most common use case I guess, but would be good to finally get rid of the problem. If you have any concerns about the change, please let me know. The solution was briefly discussed with Richard on irc a couple of month ago, but if someone thinks this should be solved in some other way, please initiate a discussion :)
BR Petter
2017-05-15 06:17 skrev Petter Mabäcker:
Due to the problem fixed in
'56c677a multilib: Move redefinition of STAGING_DIR_KERNEL'
STAGING_KERNEL_DIR must be redefined for lib32 in multilib.bbclass.
However this redefinition expanded STAGING_KERNEL_DIR to an absolute
path. This unconsciously added the TMPDIR path in the sstate object,
causing packages depended on STAGING_KERNEL_DIR being rebuild if the
TMPDIR was changed.
Solve this by forcing the unexpanded TMPDIR variable to remain in the
beginning of STAGING_DIR_KERNEL (as default). Since TMPDIR is included in
BB_HASHBASE_WHITELIST, the sstate object will not be depended on the
expanded path anymore.
Signed-off-by: Petter Mabäcker <petter@technux.se>
---
meta/classes/multilib.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index ab04597..816f54e 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -4,7 +4,9 @@ python multilib_virtclass_handler () {
if cls != "multilib" or not variant:
return
- e.data.setVar('STAGING_KERNEL_DIR', e.data.getVar('STAGING_KERNEL_DIR'))
+ localdata = bb.data.createCopy(e.data)
+ localdata.delVar('TMPDIR')
+ e.data.setVar('STAGING_KERNEL_DIR', localdata.getVar('STAGING_KERNEL_DIR'))
# There should only be one kernel in multilib configs
# We also skip multilib setup for module packages.
--
1.9.1