12473 2018-01-11 14:26:51 +0000 Recipe cache not working for nested DataSmart objects (BB_ORIGENV) 2020-04-28 03:13:51 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified All Multiple RESOLVED FIXED Medium major 4.99 1 dominik.jaeger richard.purdie poky.bs.watcher poky.watcher randy.macleod stephano --- --- No (bug/feature does not impact docs) oldest_to_newest 79022 0 dominik.jaeger 2018-01-11 14:26:51 +0000 The recipe cache (activated by CACHE option) is not working if there are nested DataSmart objects. For example BB_ORIGENV is itself a DataSmart and also an entry in the main DataSmart object. The get_hash function calculates a hash based on the values of the DataSmart dict. For nested objects the value may not be persistent. In the case of the BB_ORIGENV the value contains the memory address of the object which is different each bitbake invocation. This causes the hash to change in each invocation. The hash is used in the file names of the cache files. Therefore the cache can never be used. This problem exists in this project: https://github.com/openembedded/bitbake.git Selectable versions in bugzilla don't match available tags in git so I didn't specify the version. The problem exists at least in the recent versions and on master. Below patch seems to fix it. The idea is to make the get_hash function recursive in case of nested DataSmart objects and use their hash in the main hash. But I'm not sure if this is the best way to solve it. Someone more experienced with the bitbake implementation should take a look. diff --git a/lib/bb/data_smart.py b/lib/bb/data_smart.py index 7b09af5..c0e4228 100644 --- a/lib/bb/data_smart.py +++ b/lib/bb/data_smart.py @@ -1014,7 +1014,10 @@ class DataSmart(MutableMapping): continue value = d.getVar(key, False) or "" - data.update({key:value}) + if type(value) is type(self): + data.update({key:value.get_hash()}) + else: + data.update({key:value}) varflags = d.getVarFlags(key, internalflags = True) if not varflags 86925 1 richard.purdie 2020-04-07 14:10:17 +0000 I did look into this and agree with your patch. We don't use BB_ORIGENV in the base configuration by default which is why we've not run into this. 86933 2 dominik.jaeger 2020-04-08 11:32:55 +0000 Thank you for looking into this. Would it be possible for you to integrate this patch and release a new version? I'm not familiar with the processes in this project. 87087 3 richard.purdie 2020-04-26 06:03:15 +0000 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=98f9b05875c9a989490ad98b38f8f8bcaf0ca9d8 87092 4 dominik.jaeger 2020-04-28 03:13:51 +0000 (In reply to comment #3) > http://git.yoctoproject.org/cgit.cgi/poky/commit/ > ?id=98f9b05875c9a989490ad98b38f8f8bcaf0ca9d8 Thank you!