[bitbake-devel] Bitbake / oe-core anomaly with multilibs

[Richard Purdie]

On Mon, 2013-03-18 at 14:12 -0500, Mark Hatle wrote:
> I found a strange situation today and I'm looking for an explanation to see if 
> it's a bug or not.
> 
> Between a .bb and .bbappend file, I end up with a situation where 
> "reproducer.bb" and "reproducer.bbappend" get the following:
> 
> RDEPENDS_${PN} += "hello1"
> RDEPENDS_reproducer += "hello2"
> 
> When evaluatated (bitbake -e reproducer) I get:
> 
> #
> # $RDEPENDS_reproducer [2 operations]
> #   append 
> /home/mhatle/git/oss/oe-core/local/recipes-sample/hello/reproducer_1.0.bb:16
> #     "hello2"
> #   rename from RDEPENDS_${PN} data.py:161 [expandKeys]
> #     " hello1"
> # computed:
> #   " hello1"
> RDEPENDS_reproducer="hello1"
> 
> So that tells me that it was initially set to "hello2", and then the ${PN} 
> expansion occurred, causing it to be set to "hello1".
> 
> So my first question is, should this be "hello1", "hello2", "hello1 hello2" or 
> "hello2 hello1"?

expandKeys tramples existing values so that result doesn't surprise me
even if its not what you expect.

> The second issue is a bit stranger.. if I change the build from "reproducer" to 
> "lib32-reproducer", I get a different result:
> 
> # $RDEPENDS_lib32-reproducer [3 operations]
> #   rename from RDEPENDS_${PN} data.py:161 [expandKeys]
> #     " hello1"
> #   rename from RDEPENDS_reproducer classextend.py:95 [rename_package_variables]
> #     " hello2"
> #   set classextend.py:71 [map_depends_variable]
> #     "lib32-hello2"
> # computed:
> #   "lib32-hello2"
> RDEPENDS_lib32-reproducer="lib32-hello2"
> 
> This time the system pulled in the ${PN} version first (obviously expanded it), 
> and then turned out and found the RDEPENDS_reproducer, and remapped it to 
> RDEPENDS_lib32-reproducer replacing the origin ${PN} version.
> 
> So I have two concerns, the first is the value is 'different' from the 
> non-multilib version, and second, what should the expected output be for this item?

Again, I'm not surprised. The multilib remapping code gets executed at
the end, after expandKeys and in this case last wins. So I can see why
the system is doing it, even if you don't like the end result.

Setting multiple conflicting keys like this is dangerous :(

We've tried to fix this before and ended up just digging deeper holes
with more problems.

Cheers,

Richard